Re: [OpenStack-Infra] Sydney Infra evening
Thanks for setting this up, I'm in. Cheers 2017-11-07 20:13 GMT+01:00 Ian Wienand : > Let's meet at the swirlly fountain pit about 6:10pm > > Preliminary plan is a ferry, dinner, walk and drinks > > Not to sound like your Mum/Mom but a light jacket and comfortable shoes > suggested :) > > -i > > On 1 Nov. 2017 10:59 am, "Ian Wienand" wrote: > > On 10/18/2017 05:37 PM, Ian Wienand wrote: > >> Hi all, >> >> As discussed in the meeting, I've started a page for planning an infra >> evening in Sydney (but note -- ALL welcome) >> >>https://ethercalc.openstack.org/lx7zv5denrb9 >> > > It looks like Wednesday night (8th) and the more active/pub crawl > option for those interested. > > Cheers, > > -i > > > > ___ > OpenStack-Infra mailing list > OpenStack-Infra@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra > ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] About aarch64 third party CI
2017-06-09 22:18 GMT+02:00 Paul Belanger : > On Fri, Jun 09, 2017 at 07:58:44PM +, Jeremy Stanley wrote: > > On 2017-06-07 14:26:10 +0800 (+0800), Xinliang Liu wrote: > > [...] > > > we already have our own pre-built debian cloud image, could I just > > > use it and not use the one built by diskimage-builder? > > [...] > > > > The short answer is that nodepool doesn't currently have support for > > directly using an image provided independent of its own image build > > process. Clark was suggesting[*] in IRC today that it might be > > possible to inject records into Zookeeper (acting as a "fake" > > nodepool-builder daemon basically) to accomplish this, but nobody > > has yet implemented such a solution to our knowledge. > > > > Longer term, I think we do want a feature in nodepool to be able to > > specify the ID of a prebuilt image for a label/provider (at least we > > discussed that we wouldn't reject the idea if someone proposed a > > suitable implementation). Just be aware that nodepool's use of > > diskimage-builder to regularly rebuild images is intentional and > > useful since it ensures images are updated with the latest packages, > > kernels, warm caches and whatever else you specify in your elements > > so reducing job runtimes as they spend less effort updating these > > things on every run. > > > > [*] http://eavesdrop.openstack.org/irclogs/%23openstack- > infra/%23openstack-infra.2017-06-09.log.html#t2017-06-09T15:32:27-2 > > > -- > > Jeremy Stanley > > Actually, I think 458073[1] aims to fix this use case. I haven't tired it > myself but it adds support for using images which are not built and > managed by > nodepool. > > This is currently only on feature/zuulv3 branch. > > [1] https://review.openstack.org/#/c/458073/ > > That's right, support for cloud-images on feature/zuulv3 is now merged and working. I just setup a Nodepool using this new feature over the weekend. This is a nodepool.yaml that can help you get going: http://paste.openstack.org/show/612191/ HTH > > ___ > > OpenStack-Infra mailing list > > OpenStack-Infra@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra > > > ___ > OpenStack-Infra mailing list > OpenStack-Infra@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Boston 2017 Summit dinner
Monday works better for me, thanks Paul! 2017-05-04 17:30 GMT+02:00 Paul Belanger : > On Thu, May 04, 2017 at 10:45:36AM -0400, Paul Belanger wrote: > > On Thu, Apr 27, 2017 at 08:47:58PM -0400, Paul Belanger wrote: > > > Greetings! > > > > > > Its that time where we all try to figure out when and where to meet up > for some > > > dinner and drinks in Boston. While I haven't figure out a place to eat > > > (suggestion most welcome), maybe we can decide which night to go out. > > > > > > As a reminder, the summit schedule has 2 events this year that people > may also > > > be attending: > > > > > > Mon 8, 6:00pm - 7:30pm - Marketplace Mixer > > > Tue 9, 7:00pm - 10:00pm - StackCity Boston at Fenway Park > > > > > > Please take a moment to reply, and which day may be better for you. > > > > > > Sunday: Yes > > > Monday: Yes > > > Tuesday: No > > > Wednesday: Yes > > > Thursday: No > > > > > > And, if you have a resturant in mind, please share. > > > > > Looks like Sunday might be our best day? Is there any objection on maybe > having > > some early dinner and drinks that day? > > > > Since nobody has suggested a location, I am going to attempt > reservations at > > http://thesaltypig.com/ @ 5pm. > > > Okay, some changes. I had a few people reach out to me, new date and time > is > 8:00pm on Monday for http://thesaltypig.com/. > > I suggest maybe we meet at the summit mixer and walk over to the restaurant > together. > > Expect an email on Monday for an exact location to meet. > > -PB > > ___ > OpenStack-Infra mailing list > OpenStack-Infra@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra > ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Boston 2017 Summit dinner
Hey folks I can do any day except Thursday, flying back Spain in the evening. Cheers! 2017-04-28 17:12 GMT+02:00 Clark Boylan : > On Thu, Apr 27, 2017, at 05:47 PM, Paul Belanger wrote: > > Greetings! > > > > Its that time where we all try to figure out when and where to meet up > > for some > > dinner and drinks in Boston. While I haven't figure out a place to eat > > (suggestion most welcome), maybe we can decide which night to go out. > > > > As a reminder, the summit schedule has 2 events this year that people may > > also > > be attending: > > > > Mon 8, 6:00pm - 7:30pm - Marketplace Mixer > > Tue 9, 7:00pm - 10:00pm - StackCity Boston at Fenway Park > > > > Please take a moment to reply, and which day may be better for you. > > > > Sunday: Yes > > Monday: Yes > > Tuesday: No > > Wednesday: Yes > > Thursday: No > > > > And, if you have a resturant in mind, please share. > > > > -PB > > > > ___ > > OpenStack-Infra mailing list > > OpenStack-Infra@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra > > For me: > > Sunday: Yes > Monday: Yes > Tuesday: No > Wednesday: Yes > Thursday: Yes > > And I have never been to Boston before so am not much help selecting a > location. > > Clark > > ___ > OpenStack-Infra mailing list > OpenStack-Infra@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra > ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] PTG team dinner?
I appreciate, happy to pitch in for offsite tasks. Will def. keep an eye on channel. Safe travels! 2017-02-16 17:06 GMT+01:00 Jeremy Stanley : > On 2017-02-16 17:02:48 +0100 (+0100), Ricardo Carrillo Cruz wrote: > > Gah, too bad I won't be able to make the PTG, didn't get budget for it. > > > > Enjoy folks, I'll miss you all! > > You'll be missed! I'll make sure there's some good summaries > afterward though, and we'll attempt to coordinate some work in IRC > as well for people who want to chip in remotely on tasks that don't > need much face-to-face bandwidth. I don't know how well it'll work > out in practice, but it's worth a try anyway. > -- > Jeremy Stanley > > ___ > OpenStack-Infra mailing list > OpenStack-Infra@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra > ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] PTG team dinner?
Gah, too bad I won't be able to make the PTG, didn't get budget for it. Enjoy folks, I'll miss you all! Cheers 2017-02-16 17:00 GMT+01:00 Jeremy Stanley : > On 2017-02-15 14:58:29 -0800 (-0800), Clark Boylan wrote: > [...] > > Alright, with Monty's help we now have a reservation at Poor Calvin's > > for Monday the 20th at 7pm. The reservation is for 14 and under my name, > > Clark Boylan. See you there! (and at the PTG). > > Clark and Monty, huge thanks for arranging this for us! > -- > Jeremy Stanley > > ___ > OpenStack-Infra mailing list > OpenStack-Infra@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra > ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Scheduling a Zuul meeting
22:00 UTC works for me too, even if it's a bit late for me. Cheers 2016-11-03 23:02 GMT+01:00 Joshua Hesketh : > Hey, > > So selfishly speaking this is early for me (particularly when daylight > savings ends). Would people consider 2200 or 2300? > > I suspect though this will make it hard for those in Europe so it's likely > no viable. In this case 2000 is okay. > > Cheers, > Josh > > On Thu, Nov 3, 2016 at 8:20 AM, Ian Wienand wrote: > >> On 11/03/2016 04:30 AM, James E. Blair wrote: >> >>> Please let me know if the proposed time (Monday, 20:00 UTC) works for >>> you, or if an alternate time would be better. >>> >> >> This should be fine for us antipodeans :) 19:00 is also OK, but starts >> getting pretty early in (our) winter >> >> -i >> >> >> ___ >> OpenStack-Infra mailing list >> OpenStack-Infra@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra >> > > > ___ > OpenStack-Infra mailing list > OpenStack-Infra@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra > > ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Scheduling a Zuul meeting
Works for me. Thanks 2016-11-02 19:46 GMT+01:00 David Shrewsbury : > Mon 20:00 UTC is fine with me. > > On Wed, Nov 2, 2016 at 1:30 PM, James E. Blair > wrote: > >> Hi, >> >> Recently, a bunch of folks have expressed an interest in helping with >> Zuul v3. With more than a handful of people engaged in active >> development, it seems like it might be time to adopt some useful >> development practices. One of those is scheduling a weekly meeting, the >> other is task tracking. >> >> The meeting would be a time and place for everyone engaged in Zuul >> development to discuss what they are doing with everyone else, get into >> as much detail as is needed, and help us ensure we're making the >> progress we want to. >> >> Of course, we will still use the #zuul channel to talk about things as >> they come up. And we will still participate in the Infrastructure >> meeting as needed to coordinate with the wider team. >> >> As our team includes people in the Middle East, Europe, North America, >> and Oceania, I propose that we schedule the meeting for Monday at 20:00 >> UTC. (19:00 would be a good alternative if 20:00 is bad for folks. >> Straying too far from that tends to make things more difficult for folks >> on either end of our timezone spectrum.) >> >> Clint Byrum (SpamapS) has volunteered to help organize the tasks needed >> to make progress and encode them into Storyboard. This will be a bit of >> a work-in-progress for a short while as we work on articulating what's >> needed to grow from a few developers to many more, but at the end of the >> process both Storyboard and our meeting should serve to provide a >> clearer picture of what needs to be done and a fluid mechanism for >> accomplishing it. >> >> Please let me know if the proposed time (Monday, 20:00 UTC) works for >> you, or if an alternate time would be better. >> >> Thanks, >> >> Jim >> >> ___ >> OpenStack-Infra mailing list >> OpenStack-Infra@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra >> > > > > -- > David Shrewsbury (Shrews) > > ___ > OpenStack-Infra mailing list > OpenStack-Infra@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra > > ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Add fuel-ccp-core group to fuel-ccp-ceph-core
Yeah, I apologize, I did that over IRC and forgot to reply this thread. Regards 2016-10-20 18:46 GMT+02:00 Elizabeth K. Joseph : > On Wed, Oct 19, 2016 at 4:19 AM, Kirill Proskurin > wrote: > > Hello Infra Team, > > > > Could you please add fuel-ccp-core[1] group to fuel-ccp-ceph-core > group[2] ? > > > > We have convention that fuel-ccp-core group is included in core groups > for > > all fuel-ccp-* repositories, and ceph[3] repo has no cores at this > moment. > > > > [1] https://review.openstack.org/#/admin/groups/1457,members > > [2] https://review.openstack.org/#/admin/groups/1600,members > > [3] https://review.openstack.org/#/c/384913/ > > Just to close the loop on this, looks like this was completed. Let us > know if anything isn't working the way you expect. > > -- > Elizabeth Krumbach Joseph || Lyz || pleia2 > > ___ > OpenStack-Infra mailing list > OpenStack-Infra@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra > ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Design summit session planning
Works for me Jeremy, thanks. Ricky 2016-10-08 17:12 GMT+02:00 Jeremy Stanley : > It's approaching time to finalize our session schedule. Just to > recap, we have five workrooms, one fishbowl and a half-day sprint > alloted. There are six good ideas on the planning pad[*] now, so > unless anyone thinks those are things we _shouldn't_ cover in one of > our six session slots or comes up with better alternative topics > _very_ quickly, it's just a matter of picking which times we want > for each topic and which one gets the fishbowl: > > 1. status update and plans for task tracking > 2. document/reset test environment expectations > 3. discuss next steps for infra-cloud > 4. interactive infra-cloud debugging > 5. plan or work on further expansion of firehose > 6. finish the Xenial jobs transition for stable/newton > > My suggestion is to put task tracking (1) in the Thursday afternoon > fishbowl as it has broad cross-project implications and presumably a > wider audience. Of the five remaining topics, two are about > infra-cloud (3,4) and two are about test environments/jobs (2,6) so > it might make the most sense to pair those up back-to-back in our > Friday morning workrooms. That leaves firehose (5) as the straggler > for the Wednesday afternoon workroom. Any other ideas? > > [*] https://etherpad.openstack.org/p/infra-ocata-summit-planning > -- > Jeremy Stanley > > ___ > OpenStack-Infra mailing list > OpenStack-Infra@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra > ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Please add me to a group
Hello Andrey I just added you to the group. Regards 2016-09-30 10:43 GMT+02:00 Andrey Nikitin : > Hello! > > I've created the following request to create new fuel-plugin's > repository: [0]. As far I can see, the project is created, so, could you > please add me to the following core group [1]? > > 0. https://review.openstack.org/#/c/377639/ > 1. https://review.openstack.org/#/admin/groups/1590,members > > -- > Andrey Nikitin > aniki...@mirantis.com > > > > ___ > OpenStack-Infra mailing list > OpenStack-Infra@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra > > ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] [openstack-dev][StoryBoard] Gerrit-StoryBoard integration is live, and other updates
Congratulations, and thanks to everyone involved in this. This is a huge milestone :-) . Cheers 2016-08-24 16:53 GMT+02:00 Zara Zaimeche : > Hi, all! A few exciting StoryBoard updates incoming. > > 1. StoryBoard is now integrated with Gerrit (thanks, zaro)! > --- > > This is the big one! And I am as happy as a clam.:) To use this > incredible new power, in StoryBoard, find the task id to the left of the > task you're about to send a patch for. Then put: > > Task: $task_id > > into the commit message. When the patch is sent, this will update the > status of the relevant task in StoryBoard, and post a comment linking to > the gerrit change. Stories also have unique ids, found to the left of each > story in the list of stories, so if you include: > > Story: $story_id > > you can easily browse from gerrit to the related StoryBoard story. There > is an example of the syntax here: > > https://review.openstack.org/#/c/355079/ > > If you'd like to try it out yourself but don't have any pressing patches > to send, you can make a story over at our test instance, > https://storyboard-dev.openstack.org , and then send a nonsense patch to > a project in review-dev (https://review-dev.openstack.org/), citing the > relevant task and/or story. > > zaro has done the vast majority of the work on this, so thank you, zaro > (again)!!! And thanks to everyone in the infra team who helped with reviews > to config and switching things on. :) > > 2. Worklists and boards are more discoverable > - > > Now logged-out users can easily find the lists of worklists and boards, > and users can filter them by title, or by tasks or stories they contain. > You'll find them on the main sidebar, just below the 'dashboard' option. A > worklist lets you order a custom todo list (eg: to convey priority), or > provide a handy filter of tasks/stories (eg: 'show all 'todo' tasks in > story foo). A board allows you to create several lists side-by-side, so > that you can track the movement of tasks. This means you can, say, create a > board with 'todo', 'review', and 'merged' lanes, filtered by project, and > the contents of these will update as people send patches to gerrit. Here's > an example: > > https://storyboard.openstack.org/#!/board/14 > > 3. More usable developer docs > - > > Matthew Bodkin has updated our developer docs so that they can be used to > launch a StoryBoard instance. They should be functional now (we aim for the > stars). Thanks, Matthew! He's also helped with multiple misc ui fixes > recently, so thanks again. > > On the horizon... > - > > There is a TC Ocata goal to remove incubated oslo code, which affects two > StoryBoard projects (the api and the python client). I've made a story for > it over here: https://storyboard.openstack.org/#!/story/2000707 ; if > other affected projects are using StoryBoard, it makes sense to list tasks > there so they're easier to find. This is exactly the sort of cross-project > work that StoryBoard is designed for, so let's give it a workout! I could > do with some guidance or examples on removing and replacing the incubated > oslo code (especially for the python client, which uses the old apiclient > module). If people are interested in running scripts against StoryBoard and > doing more specific browses and filters on results, our python client is > the answer, so I'm interested in a) tidying it up and b)finding out > people's workflow and how they would expect to interact with the python > client from the commandline. > > That's all for now (sorry this was so long!). The StoryBoard meeting is at > 15:00 UTC today (and every Wednesday) in #openstack-meeting. We are also > always available in #storyboard, for chatter (and occasionally > development). Happy task-tracking! :) > > Best Wishes, > > Zara > > ___ > OpenStack-Infra mailing list > OpenStack-Infra@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra > ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Work toward a translations checksite and call for help
Oh, hahaha, I thought the dns.py was actually doing something. Now that I see the script I know what you mean :-). 2016-08-01 17:10 GMT+02:00 Jeremy Stanley : > On 2016-08-01 16:46:07 +0200 (+0200), Ricardo Carrillo Cruz wrote: > > In my mind, I thought set_dns would be really an ansible wrapper to > > system-config launch/dns.py script. > [...] > > There's a reason why that script only tells you what commands to > run, and doesn't run them for you. At least that way we can still > assert that we're not writing automation to communicate with > Rackspace's (proprietary, non-free, nonstandard, non-OpenStack) DNS > API if a sysadmin has to manually run commands to update records > through it. Then it's no worse on a philosophical level than using a > Web browser to make DNS changes through their similarly proprietary > dashboard site. > -- > Jeremy Stanley > > ___ > OpenStack-Infra mailing list > OpenStack-Infra@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra > ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Work toward a translations checksite and call for help
In my mind, I thought set_dns would be really an ansible wrapper to system-config launch/dns.py script. But yeah, putting the switch on what's Devstack latest and what's not on an Apache reverse proxy works too. The workflow would be similar to what I depicted. I think the biggest issue is that DevStack really gives a lot of problems when you try to stack/unstack , so long-lived servers are asking for trouble here. 2016-08-01 16:36 GMT+02:00 Jeremy Stanley : > On 2016-08-01 16:08:49 +0200 (+0200), Ricardo Carrillo Cruz wrote: > [...] > > The set DNS task would check a file on the puppetmaster which contains > the > > state of blue/green DNS records (translate-latest.openstack.org > pointing to > > translate_a and translate-soon-to-be-deleted.openstack.org pointing to > > translate_b or viceversa) and would only run in case any of the preceding > > create_server tasks did anything. > [...] > > Problem is we can't (okay, shouldn't) automate DNS changes while > we're relying on Rackspace's DNS service, since it's not using a > standard OpenStack API and we really don't want to write additional > tooling to it. > > As mentioned in my earlier E-mail, a simple alternative is to just > update a HTTP 302 (temporary) redirect or a rewrite/proxy to the > "live" deployment in an Apache vhost on static.openstack.org or > perhaps update a persistent haproxy pool. Proxying rather than > redirecting probably makes the most sense as we can avoid presenting > IP-address-based URLs to the consumer (and if we're forced to deploy > with TLS then we might be able to stabilize a solution for that at > the proxy too). > -- > Jeremy Stanley > > ___ > OpenStack-Infra mailing list > OpenStack-Infra@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra > ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Work toward a translations checksite and call for help
How about something like a playbook that runs on puppetmaster periodically doing something like this: create_server_translate_a create_server_translate_b set_dns The create_server_translate tasks would be idempotent, i.e. they won't leak servers. The set DNS task would check a file on the puppetmaster which contains the state of blue/green DNS records (translate-latest.openstack.org pointing to translate_a and translate-soon-to-be-deleted.openstack.org pointing to translate_b or viceversa) and would only run in case any of the preceding create_server tasks did anything. Then at $DAYS, we have a cron task that deletes whatever server is blue (or green, none of those colors are my favorites :-), swapping A is Blue/B is green or viceversa. The main play from above for recreating them would pick up and create a new server and do the needful from DNS perspective. Thoughts? 2016-07-25 19:05 GMT+02:00 Jeremy Stanley : > On 2016-07-25 11:08:35 +0530 (+0530), Vipul Nayyar wrote: > > Honestly, I was also thinking that using containers for implementing > > blue/green deployment would be best for implementing minimal downtime. I > > suggest having a basic run-through of this idea with the community over > > tomorrow's irc meeting should be a good start. > > Waving containers at the problem doesn't really solve the > fundamental issue at hand (we could just as easily use DNS or an > Apache redirect to switch between virtual machines, possibly more > easily since we already have existing mechanisms for deploying and > replacing virtual machines). The issue that needs addressing first, > I think, is how to get new DevStack deployments from master branch > tip of all projects to work consistently at each rebuild interval > or, more likely, to design a pattern that avoids replacing a working > deployment with a broken one along with some means to find out that > redeployment is failing so that it can effectively be troubleshot > post-mortem. > -- > Jeremy Stanley > > ___ > OpenStack-Infra mailing list > OpenStack-Infra@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra > ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Need membership in gerrit group
Hello Amit I've added you to the groups requested. Kind regards 2016-07-27 10:46 GMT+02:00 Amit Saha : > Hi, > > We are in the process of creating a StackForge project and got our initial > approval (https://review.openstack.org/#/c/346394/4). > > As per the documentation at > http://docs.openstack.org/infra/manual/creators.html#update-the-gerrit-group-members, > the OpenStack Infra team can help me (ams...@gmail.com) get added to the > Gerrit groups: > >- python-don-core >- python-don-release > > Can someone help me with that? > > Regards, > Amit > > -- > Smugmug coupon code: pwzn27r9CVvSg > > ___ > OpenStack-Infra mailing list > OpenStack-Infra@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra > > ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Installing Zuul without the openstack-infra Puppet
Absolutely. As a matter of fact, the OpenStack Infra CI no longer has a Puppetmaster daemon running. The current puppetmaster.openstack.org is a host containing hiera and puppet modules. A cron'd Ansible play pushes to the clients the pertinent hiera secrets and modules for each node and then runs puppet apply. It's thus a puppetmaster-less setup. I recommend you take a look at https://git.openstack.org/cgit/openstack-infra/puppet-openstackci/ . Puppet-openstackci is a project that contains puppet modules to install an OpenStack based CI, and of course it has manifests/classes for Zuul. Regards 2016-06-11 0:16 GMT+02:00 Coggins, Dean (OTSI Contractor) < dean.cogg...@hpe.com>: > Hello, > > > > I’ve been asked to set up a Zuul environment for the HPE Networks switch > development environment. I already have Gerrit and Jenkins master/slave > servers up and running in our environment. These servers were set up by > myself manually, outside of the openstack CI processes. > > > > In reading the documentation at > http://docs.openstack.org/infra/system-config/running-your-own.html, it > indicates that I need to set up a puppet master server using the openstack > system-config and project-config repositories. We already have a puppet > managed environment in the Lab. Will the openstack puppet-zuul work with a > non openstack puppet process? Or, am I required to use an openstack puppet > environment for the install and setup? > > > > *Regards,* > > *Dean Coggins* > > > *dean.cogg...@hpe.com *Software Engineer > Object Technology Solutions, Inc. (OTSI) contractor > HPE Roseville – R3U (R7) > > +1 916 785 3263 Office > > +1 650 316 2386 Skype Office > > > > ___ > OpenStack-Infra mailing list > OpenStack-Infra@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra > > ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Infra priorities and spec cleanup
I'd be happy to look at those issues, so if you can create a story with tasks that would be great. Ricky 2016-06-07 0:42 GMT+02:00 Spencer Krum : > > > Ansible Puppet Apply > > > > > > > http://specs.openstack.org/openstack-infra/infra-specs/specs/ansible_puppet_apply.html > > > > This seems to be basically done and in production, modulo some bugs > > identified in our session in Austin: > > > > https://etherpad.openstack.org/p/newton-infra-robustify-ansible-puppet > > > > I think it needs to stay on the priority list until these are fixed, > > or we need to enumerate those still outstanding as bugs in search of > > a fix (and consider the spec implemented just buggy) if they won't > > be fixed in the very near future. > > > > It is online and in production at least. There are some rough edges we > need to work out for sure, especially around reporting. I am working on > solving these issues but I only have so much time for upstream right now > (read: not a lot). > > If other people want to hop on this and don't know where to go or where > to start with it I'd be happy to flesh out steps in stories or a quick > chat. Otherwise I'll probably just work on it. > > > Common OpenStack CI Solution > > > > > > > http://specs.openstack.org/openstack-infra/infra-specs/specs/openstackci.html > > > > This seems done, other than the logstash/kibana module migration > > which is currently underway. It makes sense to leave this on the > > priority list until it's done (which should be very, very soon from > > the look of things). > > > > I agree that the initial spec is complete. There is (and perhaps always > will be) follow up specs to expand the scope out to include even more of > our infrastructure. > > > -- > Spencer Krum > n...@spencerkrum.com > > ___ > OpenStack-Infra mailing list > OpenStack-Infra@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra > ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] The future of our server naming patterns
2016-05-23 22:38 GMT+02:00 Jeremy Stanley : > As discussed during the "Launch Node, Ansible and Puppet" summit > session in Austin[1], we're making things unnecessarily hard on > ourselves by insisting on having multiple servers in our inventory > with the same name. In order to make server addition and replacement > automation simpler, lets start using an ordinal suffix on server > short names to differentiate them (we can still easily rely on DNS > for their non-numbered convenience names). > > ++ on this. As we are moving towards putting more and more automation and Ansible in general, putting ourselves in a position where we can't have two different Gerrits/whatever with the same name in the inventory will make give us a *lot* of peace of mind when running plays, as we don't have a test/staging/prod workflow and we just throw changes via code-review or by hand. Ricky ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] [OT] Call for speaker submissions
I appreciate you starting this thread Paul. Being able to collaborate with other folks from the infra team on preparing talks for confs is great, and gives the chance to people who are interested in the project but are 'shy' to speak up alone in stage to overcome that barrier. This will also avoid having talks with repeating topics on same/similar confs. Looking forward to collaborate on upcoming confs :-) . Ricky 2016-05-02 20:55 GMT+02:00 Spencer Krum : > I think this is a good conversation to have. I would recommend we start > a thread-per-conference for simplicity. Folks can use this to coordinate > attendance, ensure we submit unique presentations, and to help each > other groom presentations. I doubt that anyone on the team would feel > any offense at someone else submitting on infra topics, but coordination > sounds good. Whenever we are presenting on an infra topic, being clear > to put credit for building and supporting the technology in the correct > place is something we should be careful to do. > > We've always used the publications repo to archive an collaborate on > talks, but I think our use of that isn't quite correct at this time. > > On Mon, May 2, 2016, at 11:31 AM, Paul Belanger wrote: > > Greetings, > > > > Now that OpenStack Austin has come and gone, I was hoping to continue the > > dialog about speaking opportunity for other conferences. One of my > > personal > > goals this year is to talk more about the tooling we support to other > > people > > and projects. Projects like nodepool, zuulv2.5, grafyaml and bindep come > > to > > mind. > > > > However, I am reluctant on submitting talks to other conferences without > > giving > > some sort of heads up to everybody. I think how we collaborated on our > > Austin > > talks worked quiet well and what I guess I am asking should we consider > > doing to > > same for other conferences? > > > > Or I am just being paranoid. > > > > PB > > > > ___ > > OpenStack-Infra mailing list > > OpenStack-Infra@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra > > > -- > Spencer Krum > n...@spencerkrum.com > > ___ > OpenStack-Infra mailing list > OpenStack-Infra@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra > ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Openstack Infra's puppet manifests and Puppet style guide.
I think it's 'ok' to try to tidy up the modules a bit, but I would put the expectation that this is not a priority for reviewers. And honestly, I don't think we should ever lint on tests this kind of styling. What I believe is something that you could change is pause a bit the refactoring, the review queue has got somewhat flooded by these changes this last week. Regards 2016-03-24 14:46 GMT+01:00 Yolanda Robla Mota : > I did an effort to review that, and some of the patches are merged. > Although it's low priority, in general these patches have improved > readability, and in some of the cases, have grouped the parameters in a > more logical way. I always tend to space the parameters myself, and keep > them ordered in a logical way because they are easier to maintain later, so > I agreed with that patch, even if that was not reflecting style guides. And > I also appreciate the high effort that Andrey has put on it. > > However, I can see there is a cost to maintain the modules that way. I > will not -1 for that, I found one case and i just suggested to keep the > order, but I think it's not a reason for people to refactor a patch. > > That's my two cents. > > Best > Yolanda > > El 24/03/16 a las 14:38, Jeremy Stanley escribió: > > On 2016-03-24 13:42:58 +0300 (+0300), Andrey Nikitin wrote: >> >>> By this message I want to start a discussion about using of the >>> Puppet style guide [0] in the 'openstack-infra/puppet-*' projects. >>> As you can see, I've created a lot of change-requests to the >>> repositories some days ago. I started this work, because I saw, >>> that those manifests have different styles of the code, therefore >>> I wanted to refactor and make much better them. For example, some >>> of them have unsorted and unstructured lists of variables, some of >>> them have no docstrings in the body with description of used >>> variables and so on. I suppose, that we can unify those manifests >>> by following the puppet style guide, but opinions are divided. >>> >> I don't think opinions are especially divided about rules mandated >> by the style guide, so much as other changes you were introducing >> not mandated by the style guide (alphabetizing class parameters, >> aligning = assignment operators, et cetera). >> >> My point of view is following: if we implement the style guide on >>> puppet manifests, we will have unified and structured manifests >>> with documentation for all classes. We can use it without >>> alphabetically sorting of variables, of course. >>> >>> So, my questions to you are: >>> 1. Should we follow the style guide or not? >>> 2. What the recommendation we could implement on Openstack Infra >>> manifests? >>> >> We've already stated in the past that for any modules besides >> openstack_project (system-config), i.e. those we're publishing to >> Puppetforge, we would follow rules mandated by the Puppet Style >> Guide. I think things like making sure we declare required >> parameters before optional ones, use docstrings for clarity, and so >> on are fine. Just be aware that changes which refactor otherwise >> syntactically and logically correct code will be low priority for >> most of our reviewers and will likely have to be rebased many times >> if they touch a lot of lines in a given file. >> > > -- > Yolanda Robla Mota > Cloud Automation and Distribution Engineer > +34 605641639 > yolanda.robla-m...@hpe.com > > > > ___ > OpenStack-Infra mailing list > OpenStack-Infra@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra > ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Network Requirements for Infracloud Relocation Deployment
Nod, it is the right time to ask for this. Regards 2016-03-22 20:07 GMT+01:00 Paul Belanger : > On Tue, Mar 22, 2016 at 11:45:12AM -0700, Colleen Murphy wrote: > > On Mon, Mar 21, 2016 at 10:17 AM, Colleen Murphy > > wrote: > > > > > On Thu, Mar 17, 2016 at 11:48 AM, Colleen Murphy > > > wrote: > > > > > >> The networking team at HPE received our request and would like to > have a > > >> call next week to review it. Our liaison, Venu, should have a draft > network > > >> diagram we can review. Who would like to join, and what times/days > work > > >> best? I would propose Tuesday at 1800 UTC (one hour before the Infra > > >> meeting). > > >> > > >> Colleen > > >> > > > A call has been scheduled for 1800-1845 UTC on Tuesday, March 22. > > > Invitations were sent out to folks who expressed interest in attending > and > > > I can share the meeting phone number and conference ID with anyone who > was > > > missed. > > > > > > Allison brought up using the asterisk server for the call and it was > not > > > responded to - I suspect either they didn't understand or didn't feel > > > comfortable with it. It would be my preference to not push the issue, > as > > > they are extending the invitation to us, not the other way around. > Instead > > > I can commit to taking and dispersing detailed notes. > > > > > > Colleen > > > > > Notes from today's meeting: > > > > 1) 1G or 10G? > > - 10G useful for image transfers and mirrors in cloud > > - Venu to connect with DC ops ensure 10G > > > > 2) ipv6? > > - Venu to ask verizon to activate /48 block, will take a couple of days > > > > 3) how many vlans? > > - one untagged for pxe/management, one tagged for public > > > I had to drop off after this point, but did we talk about them (HP team) > wiring > up 2 network interfaces, assuming our NICs support it? I know we > currently are > doing everything with a single interface. > > Even if we continue to use the single NIC, asking to have the 2nd wired > might be > worth it for down the road. > > > 4) keep 10.10.16.0/24 for internal network > > > > 5) Do we need nic bonding? > > - no > > > > 6) Any load balancing requirement? > > - no > > - if we were to add load balancing we would host it ourselves > > > > 5) Access requirements? > > - full inbound/outbound internet access - no ports blocked > > - firewalls managed locally > > > > The network diagram will need to have some parts redacted before we can > > share it publicly. > > > > Colleen > > > ___ > > OpenStack-Infra mailing list > > OpenStack-Infra@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra > > > ___ > OpenStack-Infra mailing list > OpenStack-Infra@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra > ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Network Requirements for Infracloud Relocation Deployment
Works for me, I'll attend. Regards 2016-03-17 22:11 GMT+01:00 Yolanda Robla Mota : > Works for me, thanks! > > El 17/03/16 a las 19:48, Colleen Murphy escribió: > > The networking team at HPE received our request and would like to have a > call next week to review it. Our liaison, Venu, should have a draft network > diagram we can review. Who would like to join, and what times/days work > best? I would propose Tuesday at 1800 UTC (one hour before the Infra > meeting). > > Colleen > > > ___ > OpenStack-Infra mailing > listOpenStack-Infra@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra > > > -- > Yolanda Robla Mota > Cloud Automation and Distribution Engineer+34 > 605641639yolanda.robla-m...@hpe.com > > > ___ > OpenStack-Infra mailing list > OpenStack-Infra@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra > > ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Puppet Apache Dependency Issues
I lean towards fixing now by using the new defined type and we write a spec for migrating to puppetlabs-apache (once we merge in upstream infra needs). Regards 2015-08-27 11:07 GMT+02:00 Yolanda Robla Mota : > Hi > Thanks for the explanation. As this is a topic that needs more background, > and a deeper discussion, I created an etherpad to work on it. > You can access on: > https://etherpad.openstack.org/p/puppet-httpd_vs_puppetlabs-apache > > Best > Yolanda > > El 26/08/15 a las 20:31, Spencer Krum escribió: > > Hello All, > > At the meeting on August 25th, we discussed an issue with the puppet-httpd > module and a few solutions. The issue is that the httpd_mod type does not > have a baked-in ordering relationship with the Service['httpd'] resource. > This means that sometimes httpd_mod resources are instantiated after the > service attempts to come up, meaning the service cannot start. > > A few solutions have been proposed: > > 1) Modify our use of the httpd_mod resource to use 'before' everywhere. > This patch [1] is an example of doing that for puppet-gerrit, we'd have to > perform similar modifications elsewhere in our code. > > 2) Modify the httpd module to do this automatically. This patch [2] > changes the type at the ruby layer using puppet internal apis to add an > 'autobefore' on the Service['httpd'] resource. > > 3) Create an httpd::mod defined type that can do this automatically. We'd > have to then change every invocation of httpd_mod to be httpd::mod. This > patch [3] is the patch to create httpd::mod and this patch [4] shows what > using it would be like. We'd have to apply changes like [4] everywhere in > our infrastructure. > > 4) Migrate to puppetlabs-apache. This has two forms, one(4a) involving > patching that module to support our usecase and the other(4b) where we use > the existing api. > > I have my own opinions about what we should be doing, but this message is > meant to explain the problem and roads available to us, not to editorialize. > > [1] https://review.openstack.org/#/c/216708/ > [2] https://review.openstack.org/#/c/216436/ > [3] https://review.openstack.org/#/c/216835/ > [4] https://review.openstack.org/#/c/217334/ > > -- > Spencer Krum > (619)-980-7820 > > > ___ > OpenStack-Infra mailing > listOpenStack-Infra@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra > > > -- > Yolanda Robla Mota > Cloud Automation and Distribution Engineer+34 > 605641639yolanda.robla-m...@hp.com > > > ___ > OpenStack-Infra mailing list > OpenStack-Infra@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra > > ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Using ensure=>running by default in Puppet modules
I lean towards the second option that Jeremy pointed out. External users just expect Puppet to bring up services configured by the module, it makes sense to me having 'running' as default and override that at the node or wrapper module. Regards El 13/8/2015 8:30, "Yolanda Robla Mota" escribió: > Hi > It's great that you expose that because this review passed through a lot > of eyes and we all +2, we all assumed that the manifest not managing > the zuul services was a bug. > From my perspective, i see advantages on puppet managing these > services, but I can understand that not all end users will want the > same. > Advantages I see for managing services are: > > 1. Manual intervention. If you don't have any extra orchestration > layer on top, such as ansible, you need manual steps to spin up these > services. That can be a blocker for some workflows, such as > automated testing. > > 2. Reliability. It can be better or worse option, but letting puppet > manage the services can be a life-saver if for some reason the > service goes down. For example i've had several problems with zuul-merger > services being down and no one noticing it until reviews started to > fail. Having puppet watching these cannot be the better solution but > it works on the simplest environments. > > So having said that, i think that the parameter option is a good one. > Provide a parameter to zuul, to show if we want it to manage the > services or not, and let end users decide. > > Best > Yolanda > > El 12/08/15 a las 23:15, Jeremy Stanley escribió: > >> Change https://review.openstack.org/168306 for puppet-zuul came to >> my attention earlier today when it merged. After a quick discussion >> on IRC, Spencer proposed a revert which I approved so that we can >> get a little more discussion going about this topic. >> >> First, I'm really sorry I didn't see and weigh in on it sooner (it's >> not like I didn't have time, it was ~4.5 months old). Second, we've >> grown lots of new core reviewers and I'm thrilled they're reviewing >> and approving changes, and I don't want to discourage that in any >> way, so thank you to those of you who did review that change. >> >> In the past, not using ensure=>running on services in our Puppet >> modules was intentional, particularly for more stateful services, >> especially for services which trigger other (possibly remote) >> actions and have a potential to make a mess. It's pretty likely that >> those of us who were around for the earlier discussions about it >> failed to write it down anywhere obvious, leading others to assume >> it's a bug/oversight. I see a couple of obvious solutions though >> there are no doubt others: >> >> 1. Document in each module where we do this, at least in the readme >> and probably also in an inline comment around the service >> definition, that it's that way on purpose. Optionally, make the >> ensure conditional on a class parameter that defaults to unmanaged >> in case some downstreams want to use Puppet like a service manager. >> >> 2. Similar managed/unmanaged parameter, but make it default to >> running and override the default to unmanaged in our >> ::openstack_project classes. This means that we cease consuming our >> modules with the same defaults as downstream users, however if it >> turns out that our OpenStack Infra root sysadmins really do have a >> very different preference from the majority of our downstream >> consumers then at least we can be clear about that. >> > > -- > Yolanda Robla Mota > Cloud Automation and Distribution Engineer > +34 605641639 > yolanda.robla-m...@hp.com > > > ___ > OpenStack-Infra mailing list > OpenStack-Infra@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra > ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Puppet lint checks for system-config
Having lint checks as non-voting seems like a good compromise to me here. 2015-08-12 17:09 GMT+02:00 Yolanda Robla Mota : > Hi > So my point here, is that i don't want to do a discrimination between > rules on puppet > modules and system-config. If we enforce lint rules, we should do it > everywhere. > > For lint in system-config, once concern was that it affects history. But > as long as we are moving > more functionality to the modules, we have this problem there as well. > > I'd like that we have common lint rules, the same for system-config and > for puppet modules. > Maybe a first step is to add lint rules to system-config as non-voting and > go gradually iterating > on it? > > That's my take. > > El 12/08/15 a las 16:56, Paul Belanger escribió: > > Greetings, >> >> This email comes from some personal frustrations regarding our code review >> policy for system-config. Specifically, lint or style checks for puppet >> code. >> >> Back in Nov. 30 2012 (yes I checked) I enabled voting for >> gate-ci-puppet-lint[1]. It was one of my first efforts for infra :) Since >> then >> we've grown to a large family of puppet contributors. >> >> However, system-config underwent a change, maybe a year ago, to remove >> lint >> checks. My understanding of the reason to disable the check, was since >> system-config was not being uploaded into the puppet forge, there was no >> need to >> have lint checks running. >> >> About 4-5 months ago, I asked to re-enable the lint check, but we denied. >> Comments revolved around git blame / history issue and wasted effort. I >> don't >> have issue with this reasoning, if people don't want to do it, I don't >> want to >> force it. >> >> However, recently. I got my hand smacked in 2 different code reviews for >> arrow >> alignment issues. Honestly, I wasn't even mad about the -1 for the >> alignment. >> However, I'm concerned about the wasted effort the -1 caused me. >> Basically, I >> had to wait a few days to get the -1, since it was a human doing the >> review, not >> the gate. Additionally, if I was getting a -1 for style checks, why didn't >> jenkins do it? >> >> So, my question is simple. What is our policy on style checks for >> system-config. From what I understand, it goes both ways. People don't >> want >> gate checksi (wasted effort), however people are doing human code review >> for >> style checks (because they like unified puppet modules). Needless to say, >> this >> is slightly confusing. >> >> All and all, I would rather jenkins give me a -1 if my code does not pass >> style >> over a human. Since, I can quickly run my tests locally before uploading >> into >> the gate. >> >> For the record, I want to re-enable the lint gate for system-config. >> This keeps >> it inline with 99% of our other openstack / openstack-infra puppet >> modules. >> >> [1] >> https://github.com/openstack-infra/project-config/commit/bee9131dce447d8dd53f246438fd3363a88da426 >> >> ___ >> OpenStack-Infra mailing list >> OpenStack-Infra@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra >> > > -- > Yolanda Robla Mota > Cloud Automation and Distribution Engineer > +34 605641639 > yolanda.robla-m...@hp.com > > > > ___ > OpenStack-Infra mailing list > OpenStack-Infra@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra > ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] [openstack-infra][puppet-pip]
Interesting, I was not aware of puppetlabs-inifile. Anyway, I think Jeremy mentioned to me that the creation of puppet-pip class was to manage the python3-python2 differences for pip paths (Jeremy can you chime in?) The manage pip.conf functionality was added afterwards (I think it was Yolanda who added that), but the main intention for this class was to install pip (which doesn't work btw). Regards 2015-08-12 14:40 GMT+02:00 Paul Belanger : > On Tue, Aug 11, 2015 at 10:59:35PM +0200, Ricardo Carrillo Cruz wrote: > > We have followed this topic on IRC channel, and it seems the consensus so > > far > > is to: > > > > 1. Deprecate python-pip from infra modules > > 2. Create another module python-pip_settings that just manages pip.conf > > (this will typically used for downstream mainly, for proxies whatnot). > > 3. Put a note on modules and documentation stating that in order to use > > infra modules install_puppet.sh should be run or pip installed prior to > > applying the puppet modules > > > > If there are no objections with the above, I'd start doing refactoring. > > > I have to admit, I didn't really follow the discussion to much yesterday. > However, what was the reason again for not using an existing > puppet-python[1] > module to do this? > > Do we really need puppet-pip_setting module or can we just not use the > puppet-inifile[2] module to manage pip.conf? > > Be kind, I haven't had coffee yet. > > [1] https://github.com/stankevich/puppet-python > [2] https://github.com/puppetlabs/puppetlabs-inifile > > > Regards > > > > 2015-08-11 12:36 GMT+02:00 Ricardo Carrillo Cruz < > > ricardo.carrillo.c...@gmail.com>: > > > > > I will add this to the infra meeting agenda, since I can't attend due > to > > > TZ differences. > > > Will put some context on what options were discussed on IRC yesterday. > > > > > > Thanks > > > > > > 2015-08-10 13:56 GMT+02:00 Jeremy Stanley : > > > > > >> On 2015-08-10 10:54:28 +0200 (+0200), Ricardo Carrillo Cruz wrote: > > >> [...] > > >> > I suggest we get rid of puppet-pip from all service puppet modules > > >> > (like puppet-zuul) and just use puppet-python for sanity (and also > > >> > adding the manage pip.conf functionality to upstream stankevich > > >> > puppet-python). > > >> [...] > > >> > > >> It would need to be made optional. On our systems, we want to have a > > >> Puppet package provider for pip but we don't want Puppet managing > > >> installation of pip because we do that through some fairly > > >> convoluted logic to forcibly purge any package-managed pip > > >> installation and run a cached copy of the get-pip.py script. See the > > >> setup_pip function in the install_puppet.sh script of > > >> openstack-infra/system-config for details. > > >> -- > > >> Jeremy Stanley > > >> > > >> ___ > > >> OpenStack-Infra mailing list > > >> OpenStack-Infra@lists.openstack.org > > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra > > >> > > > > > > > > > ___ > > OpenStack-Infra mailing list > > OpenStack-Infra@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra > > ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] [openstack-infra][puppet-pip]
We have followed this topic on IRC channel, and it seems the consensus so far is to: 1. Deprecate python-pip from infra modules 2. Create another module python-pip_settings that just manages pip.conf (this will typically used for downstream mainly, for proxies whatnot). 3. Put a note on modules and documentation stating that in order to use infra modules install_puppet.sh should be run or pip installed prior to applying the puppet modules If there are no objections with the above, I'd start doing refactoring. Regards 2015-08-11 12:36 GMT+02:00 Ricardo Carrillo Cruz < ricardo.carrillo.c...@gmail.com>: > I will add this to the infra meeting agenda, since I can't attend due to > TZ differences. > Will put some context on what options were discussed on IRC yesterday. > > Thanks > > 2015-08-10 13:56 GMT+02:00 Jeremy Stanley : > >> On 2015-08-10 10:54:28 +0200 (+0200), Ricardo Carrillo Cruz wrote: >> [...] >> > I suggest we get rid of puppet-pip from all service puppet modules >> > (like puppet-zuul) and just use puppet-python for sanity (and also >> > adding the manage pip.conf functionality to upstream stankevich >> > puppet-python). >> [...] >> >> It would need to be made optional. On our systems, we want to have a >> Puppet package provider for pip but we don't want Puppet managing >> installation of pip because we do that through some fairly >> convoluted logic to forcibly purge any package-managed pip >> installation and run a cached copy of the get-pip.py script. See the >> setup_pip function in the install_puppet.sh script of >> openstack-infra/system-config for details. >> -- >> Jeremy Stanley >> >> ___ >> OpenStack-Infra mailing list >> OpenStack-Infra@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra >> > > ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] [openstack-infra][puppet-pip]
I will add this to the infra meeting agenda, since I can't attend due to TZ differences. Will put some context on what options were discussed on IRC yesterday. Thanks 2015-08-10 13:56 GMT+02:00 Jeremy Stanley : > On 2015-08-10 10:54:28 +0200 (+0200), Ricardo Carrillo Cruz wrote: > [...] > > I suggest we get rid of puppet-pip from all service puppet modules > > (like puppet-zuul) and just use puppet-python for sanity (and also > > adding the manage pip.conf functionality to upstream stankevich > > puppet-python). > [...] > > It would need to be made optional. On our systems, we want to have a > Puppet package provider for pip but we don't want Puppet managing > installation of pip because we do that through some fairly > convoluted logic to forcibly purge any package-managed pip > installation and run a cached copy of the get-pip.py script. See the > setup_pip function in the install_puppet.sh script of > openstack-infra/system-config for details. > -- > Jeremy Stanley > > ___ > OpenStack-Infra mailing list > OpenStack-Infra@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra > ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
[OpenStack-Infra] [openstack-infra][puppet-pip]
Hi folks I would like to get a consensus on where we should go with puppet-pip and puppet-python. Puppet-pip module is supposedly for installing pip and managing pip.conf. Puppet-python (aka stankevich-python) module manages python, pip, virtualenv and gunicorn virtual hosts (serious swiss army module btw). I tried to install Zuul with the puppet-zuul module this weekend and got failures due to missing pip. I looked at the code and the module uses puppet-pip, but turns out puppet-pip does *not* install pip package as one would expect, therefore I pushed https://review.openstack.org/#/c/211016/. The patch failed on apply tests with a 'Duplicate declaration', as the slaves use puppet-python module and this *does* install python-pip on the slaves: http://logs.openstack.org/16/211016/1/check/gate-infra-puppet-apply-bare-precise/a63c7fb/console.html#_2015-08-10_07_31_50_728 Given there's quite a bit of overlap between puppet-pip and puppet-python, I suggest we get rid of puppet-pip from all service puppet modules (like puppet-zuul) and just use puppet-python for sanity (and also adding the manage pip.conf functionality to upstream stankevich puppet-python). Thoughts? Regards ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] [openstack-dev] Need help! Zuul can not connect to port 29418 of review.openstack.org
Alternatively you could have a look at tunneling SSH over HTTP with corkscrew: http://www.techrepublic.com/blog/linux-and-open-source/using-corkscrew-to-tunnel-ssh-over-http/ Regards 2015-06-12 11:09 GMT+02:00 Tom Fifield : > On 12/06/15 17:04, liuxinguo wrote: > >> Hi, >> >> Recentlyour CI can not connect to port 29418 of >> review.openstack.org. >> >> Following are the failuer message, is there anyone know the reasion why >> our CI can not cennect to 29418 of review.openstack.org? >> > > > That port on review.openstack.org currently appears to be blocked by > China country-level firewall. > > In this case, changing access from SSH to HTTPS could help avoid the > block, like in Clark's email: > > > http://lists.openstack.org/pipermail/openstack-dev/2014-September/045385.html > > > Regards, > > > Tom > > ___ > OpenStack-Infra mailing list > OpenStack-Infra@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra > ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Biting the bullet on issue tracking
Hey Michael It's a shame we are getting rid of SB, it's an amazing kit of software. I'm hoping we will be able to continue developing it, maybe not being the main issue tracker for OpenStack now will allow the project become what it was envisioned. You have been a great lead and I am looking forward to work with you again soon. Kind regards 2015-03-24 0:28 GMT+01:00 Michael Krotscheck : > Hey everyone! > > It's quite rough to realize that the thing you've been advocating, working > on, and desperately trying to recruit contributors for is DoA, and that's > what I've been struggling with for the past few weeks. Even so, I was part > and parcel to coming up with Monty's recommendation, so this wasn't a > surprise. > > Don't get me wrong: I love the project. I love the team, I love our > technological vision, I love all these things. There are features that I > feel are unique - Federation, process-agnosticism, clean api/ui separation, > etc. - and given the opportunity (and proper resources) I would love to > continue working on it. However for all the excitement that I've received > over the past year, very little has solidified into any kind of concrete > contribution. It was time to call the bluff. > > And yet... StoryBoard has been a fantastic test bed for JavaScript as a > first class citizen in OpenStack, and I'm going to continue moving that > forward. There are some missing parts of our infrastructure, some of our > existing tools need to be refined and documented, and there are some sticky > policy items that need to be proposed to the TC. I see no reason not to > continue supporting StoryBoard as that test bed, especially since the > infrastructure team is still using it. Once a reasonable sunset has been > reached (assuming new contributors don't magically materialize), my plan is > to dive into the other UI components in OpenStack. > > A very special thank you Yolanda Robla-Mota, Mike Heald, Riccardo Cruz, > Nikita Konovalov, Aleksey Ripinien, Tom Pollard, and all the others who > have contributed over the past year. Y'all are awesome. > > Michael > > On Mon, Mar 23, 2015 at 4:03 PM Monty Taylor wrote: > >> Hi everybody, >> >> First, some background: >> >> A year and a half ago, Infra started down the road of of writing a >> replacement for the pieces of Launchpad that OpenStack continues to use. >> There were several reasons, but notable amongst them are: >> >> - Desire to use the forthcoming openstackid OpenID/Oauth as an SSO >> - Delay in long-standing bugs that affect OpenStack getting fixed >> >> The existing open source offerings that we investigated did not have >> adequate feature parity in the key data model areas that made Launchpad >> particularly compelling as a choice for us, and adding what we needed to >> the existing offerings would amount to substantial rewrites ... so we >> decided that we had no real choice but to write our own. >> >> Where we're at >> >> We've gotten far enough to get Infra moved on to storyboard, but the >> project has never really gotten resourced to the level it needs to be to >> truly responsive to the needs of our community. We're making good >> progress towards meeting the initial set of goals we set, but in the >> mean time several new requests have come in - such as from the UX team >> and the Product Management Working Group - that we cannot meet today and >> which at our current rate I do not believe we would be able to meet in a >> reasonable timeframe. >> >> At the same time, the state of the art around us has improved since we >> started. A year and a half ago, I was able to very honestly say that we >> needed to work on this effort because we simply had no other choice. >> That is no longer true. Existing Open Source offerings not only can >> represent a large portion of our data needs, but additionally can >> support the additional features that have been requested by our >> community today out of the box. >> >> The combination of the two of those makes the likelihood of us being >> able to convince people to pony up more resources seem more and more far >> fetched. I could be wrong, of course - it's possible that in response to >> this someone will start jumping up and down and commit engineers to the >> effort ... but I'm not holding my breath. >> >> Biting the bullet >> >> I think we should get out of the business of writing our own bug tracker. >> >> It's not an easy thing to say, and I don't say it lightly. There are >> things that storyboard models well that continue to be things that >> simply are not modeled elsewhere. However, I think it's important to >> know when good enough will do, and I think it's important to be able to >> step up and say that we tried valiantly, and everyone involved did a >> great job, and yet the world has moved on and writing a bug tracker is >> not, at the end of the day, what we're all here to do. >> >> We're looking at what our options are, and Thierry is examining them to >> see how tolerable their d
[OpenStack-Infra] [openstack-infra][jeepyb] Deprecating jeepyb-gerrit update_bug.py hook
Hi there I was writing a spec for an issue tracker agnostic update_bug.py on Jeepyb when this Story comment from Khai came to my attention: https://storyboard.openstack.org/#!/story/212 " We should probably just deprecate jeepyb at this point. The Gerrit <-> Storyboard integrations should be done with a gerrit plugin and a storyboard plugin. I'm working on the Gerrit plugin and it's currently hosted upstream, initial change is here: https://gerrit-review.googlesource.com/#/c/60590 " Has this deprecation been agreed in a meeting or in the IRC channel? Don't want to continue with the jeepyb work if we will switch to a Gerrit-SB plugin solution. Regards ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Fwd: Launchpad group for new openstackdroid project
Yeah I know, I asked for Storyboard documentation in case we were using it already for new projects. Regards El 26/03/2014 14:59, "Jeremy Stanley" escribió: > On 2014-03-25 23:34:11 +0100 (+0100), Ricardo Carrillo Cruz wrote: > [...] > > is there any documentation for this topic of new Stackforge > > projects around? > > Launchpad is an external service written and maintained by Canonical > Ltd. (it's not managed by OpenStack's infrastructure team). Their > documentation on registering project resources can be found at: > > https://help.launchpad.net/Projects/Registering > > -- > Jeremy Stanley > ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Fwd: Launchpad group for new openstackdroid project
Cool, thanks for the info. Regards El 26/03/2014 00:16, "Joshua Hesketh" escribió: > Hi Ricardo, > > Storyboard is still under development so you should be setting up on > launchpad for now. As far as I know no date has been set for switching over > to storyboard so it is still a while down the track. > > Cheers, > Josh > > Rackspace Australia > > On 3/26/14 9:34 AM, Ricardo Carrillo Cruz wrote: > > Hello guys > > I recently got merged on stackforge a project I did for my Systems > Engineering dissertation, it's an Android openstack app: > > https://review.openstack.org/#/c/81234/ > > Following the documentation, it seems I would need to open a new request > for Launchpad groups in order to manage bugs and blueprints: > > https://wiki.openstack.org/wiki/Project_Group_Management > > However, I've been reading lately the existence of Storyboard which > apparently will replace Launchpad. > > Should I still ask for Launchpad group for openstackdroid or should I > pass and go with Storyboard? > If the latter, is there any documentation for this topic of new Stackforge > projects around? > > Thanks and kind regards > > > > ___ > OpenStack-Infra mailing > listOpenStack-Infra@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra > > > ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
[OpenStack-Infra] Launchpad group for new openstackdroid project
Hello guys I recently got merged on stackforge a project I did for my Systems Engineering dissertation, it's an Android openstack app: https://review.openstack.org/#/c/81234/ Following the documentation, it seems I would need to open a new request for Launchpad groups in order to manage bugs and blueprints: https://wiki.openstack.org/wiki/Project_Group_Management However, I've been reading lately the existence of Storyboard which apparently will replace Launchpad. Should I still ask for Launchpad group for openstackdroid or should I pass and go with Storyboard? If the latter, is there any documentation for this topic of new Stackforge projects around? Thanks and kind regards ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
[OpenStack-Infra] Fwd: Launchpad group for new openstackdroid project
Hello guys I recently got merged on stackforge a project I did for my Systems Engineering dissertation, it's an Android openstack app: https://review.openstack.org/#/c/81234/ Following the documentation, it seems I would need to open a new request for Launchpad groups in order to manage bugs and blueprints: https://wiki.openstack.org/wiki/Project_Group_Management However, I've been reading lately the existence of Storyboard which apparently will replace Launchpad. Should I still ask for Launchpad group for openstackdroid or should I pass and go with Storyboard? If the latter, is there any documentation for this topic of new Stackforge projects around? Thanks and kind regards ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
