Re: [OpenStack-Infra] Sydney Infra evening

[Ricardo Carrillo Cruz]

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

[Ricardo Carrillo Cruz]

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

[Ricardo Carrillo Cruz]

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] PTG team dinner?

[Ricardo Carrillo Cruz]

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 <fu...@yuggoth.org>:

> 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?

[Ricardo Carrillo Cruz]

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

[Ricardo Carrillo Cruz]

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

[Ricardo Carrillo Cruz]

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

[Ricardo Carrillo Cruz]

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

[Ricardo Carrillo Cruz]

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

[Ricardo Carrillo Cruz]

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

[Ricardo Carrillo Cruz]

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

[Ricardo Carrillo Cruz]

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 <fu...@yuggoth.org>:

> 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

[Ricardo Carrillo Cruz]

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 <fu...@yuggoth.org>:

> 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

[Ricardo Carrillo Cruz]

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

[Ricardo Carrillo Cruz]

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

[Ricardo Carrillo Cruz]

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] The future of our server naming patterns

[Ricardo Carrillo Cruz]

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

[Ricardo Carrillo Cruz]

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.

[Ricardo Carrillo Cruz]

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

[Ricardo Carrillo Cruz]

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

[Ricardo Carrillo Cruz]

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 yolanda.robla-m...@hp.com:

 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

[Ricardo Carrillo Cruz]

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 yolanda.robla-m...@hp.com
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] [openstack-infra][puppet-pip]

[Ricardo Carrillo Cruz]

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 pabelan...@redhat.com:

 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 fu...@yuggoth.org:
  
   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] Puppet lint checks for system-config

[Ricardo Carrillo Cruz]

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 yolanda.robla-m...@hp.com:

 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]

[Ricardo Carrillo Cruz]

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 fu...@yuggoth.org:

 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]

[Ricardo Carrillo Cruz]

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] Biting the bullet on issue tracking

[Ricardo Carrillo Cruz]

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 krotsch...@gmail.com:

 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 mord...@inaugust.com 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 differences would be to our community.

 I propose that we have a solid answer and migration plan to put 

[OpenStack-Infra] [openstack-infra][jeepyb] Deprecating jeepyb-gerrit update_bug.py hook

[Ricardo Carrillo Cruz]

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

[OpenStack-Infra] Fwd: Launchpad group for new openstackdroid project

[Ricardo Carrillo Cruz]

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