Re: [OpenStack-Infra] [openstack-dev] Zuul project evolution

[Joshua Harlow]

Awesome!

Might IMHO be useful to also start doing this with other projects.

James E. Blair wrote:

Hi,

To date, Zuul has (perhaps rightly) often been seen as an
OpenStack-specific tool.  That's only natural since we created it
explicitly to solve problems we were having in scaling the testing of
OpenStack.  Nevertheless, it is useful far beyond OpenStack, and even
before v3, it has found adopters elsewhere.  Though as we talk to more
people about adopting it, it is becoming clear that the less experience
they have with OpenStack, the more likely they are to perceive that Zuul
isn't made for them.

At the same time, the OpenStack Foundation has identified a number of
strategic focus areas related to open infrastructure in which to invest.
CI/CD is one of these.  The OpenStack project infrastructure team, the
Zuul team, and the Foundation staff recently discussed these issues and
we feel that establishing Zuul as its own top-level project with the
support of the Foundation would benefit everyone.

It's too early in the process for me to say what all the implications
are, but here are some things I feel confident about:

* The folks supporting the Zuul running for OpenStack will continue to
   do so.  We love OpenStack and it's just way too fun running the
   world's most amazing public CI system to do anything else.

* Zuul will be independently promoted as a CI/CD tool.  We are
   establishing our own website and mailing lists to facilitate
   interacting with folks who aren't otherwise interested in OpenStack.
   You can expect to hear more about this over the coming months.

* We will remain just as open as we have been -- the "four opens" are
   intrinsic to what we do.

As a first step in this process, I have proposed a change[1] to remove
Zuul from the list of official OpenStack projects.  If you have any
questions, please don't hesitate to discuss them here, or privately
contact me or the Foundation staff.

-Jim

[1] https://review.openstack.org/552637

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] taskflow requirements

[Joshua Harlow]

I can put an upper bound on the version, that's fine with me. I'd rather not 
avoid adding taskflow to wait until some new preemptive gating process is in 
place. That doesn't exactly feel fair to the people creating taskflow or the 
people using it, especially since people are integrating it at this moment and 
it would be sad for their work to be lost due to a requirement line.

As for part of oslo, cc'ing Doug since from my talks with him seem to be that 
it's just a library and to encourage the growth of useful libraries the red 
tape isn't needed (aka, taskflow has no strong ties to oslo and I'm not sure it 
should). 

Sent from my really tiny device...

> On Nov 11, 2013, at 7:33 PM, "Monty Taylor"  wrote:
> 
> There is a change up to add taskflow to the global requirements. I have
> no problem with this in principle, but it's one more that's in the set
> of things like pecan, wsme and friends that are in the set of things
> that Sean talked about in preemptively gate the universe.
> 
> I'd like to not add it until we have a plan for at least assymetrical
> gating, so that changes to taskflow at least can't break cinder and friends.
> 
> Further, I think we might need to discuss how to include libraries such
> as this. Should taskflow be a part of oslo?

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] taskflow requirements

[Joshua Harlow]

Sounds good,

Will do when I get back from HK, still here exploring :-)

Sent from my really tiny device...

> On Nov 11, 2013, at 10:17 PM, "Monty Taylor"  wrote:
> 
> Ok. Cool. Let's just put an upper bound on it for now then (mainly
> because it's listed as 0.1, so that version to me suggests that it might
> still have breaking API churn)
> 
>> On 11/11/2013 07:53 AM, Joshua Harlow wrote:
>> I can put an upper bound on the version, that's fine with me. I'd rather not 
>> avoid adding taskflow to wait until some new preemptive gating process is in 
>> place. That doesn't exactly feel fair to the people creating taskflow or the 
>> people using it, especially since people are integrating it at this moment 
>> and it would be sad for their work to be lost due to a requirement line.
>> 
>> As for part of oslo, cc'ing Doug since from my talks with him seem to be 
>> that it's just a library and to encourage the growth of useful libraries the 
>> red tape isn't needed (aka, taskflow has no strong ties to oslo and I'm not 
>> sure it should). 
>> 
>> Sent from my really tiny device...
>> 
>>> On Nov 11, 2013, at 7:33 PM, "Monty Taylor"  wrote:
>>> 
>>> There is a change up to add taskflow to the global requirements. I have
>>> no problem with this in principle, but it's one more that's in the set
>>> of things like pecan, wsme and friends that are in the set of things
>>> that Sean talked about in preemptively gate the universe.
>>> 
>>> I'd like to not add it until we have a plan for at least assymetrical
>>> gating, so that changes to taskflow at least can't break cinder and friends.
>>> 
>>> Further, I think we might need to discuss how to include libraries such
>>> as this. Should taskflow be a part of oslo?
>> 

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] taskflow requirements

[Joshua Harlow]

Sweet, let me know if u have any questions, bug me when I get back
tomorrow (spent some time in HK to travel around, since during the summit
most all the traveling was from the airport to the asiaworld) making it
hard to actually see any of hong kong (except at night). So let me know if
u want to discuss it :-)

Also: https://wiki.openstack.org/wiki/TaskFlow

-Josh

On 11/12/13 3:09 AM, "Robert Collins"  wrote:

>On 12 November 2013 22:47, Joshua Harlow  wrote:
>> Yes it's still a thing and no it's not being deprecated, I heard other
>>things from other people at rackspace say the opposite, so maybe u
>>misunderstood adrian (if or if  not rackspace is involved is there
>>choice in the end).
>>
>> So yes it's still being actively developed and yes it's gaining
>>traction. I don't see that traction slowing down. There was a lot if
>>summit sessions on it that I did so I'm not sure where u heard that it's
>>not active.
>>
>> And as for spiff sure can use that also, but IMHO u will come to the
>>same conclusions I did, that I believe spiff is functionally inferior,
>>your mileage may vary though. Likely there are use cases for both in the
>>end; feel free to do your own investigation into what each offers. Spiff
>>to me lacked a well defined state machine, was to complex and did not
>>have foundational semantics that taskflow does have (extremely important
>>ones like resumption, reversion and state persistence...). But feel free
>>to make up your own mind, it's a free world after all...
>
>Ok cool, thats good to know. I only asked because of what I was
>hearing. I will see about looking in detail in my copious free time :)
>
>-Rob
>
>-- 
>Robert Collins 
>Distinguished Technologist
>HP Converged Cloud


___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] taskflow requirements

[Joshua Harlow]

Yes it's still a thing and no it's not being deprecated, I heard other things 
from other people at rackspace say the opposite, so maybe u misunderstood 
adrian (if or if  not rackspace is involved is there choice in the end).

So yes it's still being actively developed and yes it's gaining traction. I 
don't see that traction slowing down. There was a lot if summit sessions on it 
that I did so I'm not sure where u heard that it's not active. 

And as for spiff sure can use that also, but IMHO u will come to the same 
conclusions I did, that I believe spiff is functionally inferior, your mileage 
may vary though. Likely there are use cases for both in the end; feel free to 
do your own investigation into what each offers. Spiff to me lacked a well 
defined state machine, was to complex and did not have foundational semantics 
that taskflow does have (extremely important ones like resumption, reversion 
and state persistence...). But feel free to make up your own mind, it's a free 
world after all...

-Josh

Sent from my really tiny device...

> On Nov 12, 2013, at 4:35 PM, "Robert Collins"  
> wrote:
> 
> So I'm curious - is taskflow still a thing? Adrian was saying in HK
> that Rackspace wasn't investing in it any more as another library -
> Spiffy? - was functionally superior, and there is no need to reinvent
> the wheel.
> 
> If thats the case, should Mistral be built on Spiffy, and taskflow deprecated?
> 
> -Rob
> 
>> On 12 November 2013 13:56, Joshua Harlow  wrote:
>> Sounds good,
>> 
>> Will do when I get back from HK, still here exploring :-)
>> 
>> Sent from my really tiny device...
>> 
>>> On Nov 11, 2013, at 10:17 PM, "Monty Taylor"  wrote:
>>> 
>>> Ok. Cool. Let's just put an upper bound on it for now then (mainly
>>> because it's listed as 0.1, so that version to me suggests that it might
>>> still have breaking API churn)
>>> 
>>>> On 11/11/2013 07:53 AM, Joshua Harlow wrote:
>>>> I can put an upper bound on the version, that's fine with me. I'd rather 
>>>> not avoid adding taskflow to wait until some new preemptive gating process 
>>>> is in place. That doesn't exactly feel fair to the people creating 
>>>> taskflow or the people using it, especially since people are integrating 
>>>> it at this moment and it would be sad for their work to be lost due to a 
>>>> requirement line.
>>>> 
>>>> As for part of oslo, cc'ing Doug since from my talks with him seem to be 
>>>> that it's just a library and to encourage the growth of useful libraries 
>>>> the red tape isn't needed (aka, taskflow has no strong ties to oslo and 
>>>> I'm not sure it should).
>>>> 
>>>> Sent from my really tiny device...
>>>> 
>>>>> On Nov 11, 2013, at 7:33 PM, "Monty Taylor"  wrote:
>>>>> 
>>>>> There is a change up to add taskflow to the global requirements. I have
>>>>> no problem with this in principle, but it's one more that's in the set
>>>>> of things like pecan, wsme and friends that are in the set of things
>>>>> that Sean talked about in preemptively gate the universe.
>>>>> 
>>>>> I'd like to not add it until we have a plan for at least assymetrical
>>>>> gating, so that changes to taskflow at least can't break cinder and 
>>>>> friends.
>>>>> 
>>>>> Further, I think we might need to discuss how to include libraries such
>>>>> as this. Should taskflow be a part of oslo?
>> 
>> ___
>> OpenStack-Infra mailing list
>> OpenStack-Infra@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
> 
> 
> 
> -- 
> Robert Collins 
> Distinguished Technologist
> HP Converged Cloud

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] taskflow requirements

[Joshua Harlow]

Feel free to read over this too:

http://www.slideshare.net/harlowja/taskflow-27820295

I'm not sure where the video I did at the summit is (still being uploaded??) 
but that's the slides that I went through in my speaker session.

Questions and comments welcome.

Sent from my really tiny device...

> On Nov 12, 2013, at 5:47 PM, "Joshua Harlow"  wrote:
> 
> Yes it's still a thing and no it's not being deprecated, I heard other things 
> from other people at rackspace say the opposite, so maybe u misunderstood 
> adrian (if or if  not rackspace is involved is there choice in the end).
> 
> So yes it's still being actively developed and yes it's gaining traction. I 
> don't see that traction slowing down. There was a lot if summit sessions on 
> it that I did so I'm not sure where u heard that it's not active. 
> 
> And as for spiff sure can use that also, but IMHO u will come to the same 
> conclusions I did, that I believe spiff is functionally inferior, your 
> mileage may vary though. Likely there are use cases for both in the end; feel 
> free to do your own investigation into what each offers. Spiff to me lacked a 
> well defined state machine, was to complex and did not have foundational 
> semantics that taskflow does have (extremely important ones like resumption, 
> reversion and state persistence...). But feel free to make up your own mind, 
> it's a free world after all...
> 
> -Josh
> 
> Sent from my really tiny device...
> 
>> On Nov 12, 2013, at 4:35 PM, "Robert Collins"  
>> wrote:
>> 
>> So I'm curious - is taskflow still a thing? Adrian was saying in HK
>> that Rackspace wasn't investing in it any more as another library -
>> Spiffy? - was functionally superior, and there is no need to reinvent
>> the wheel.
>> 
>> If thats the case, should Mistral be built on Spiffy, and taskflow 
>> deprecated?
>> 
>> -Rob
>> 
>>> On 12 November 2013 13:56, Joshua Harlow  wrote:
>>> Sounds good,
>>> 
>>> Will do when I get back from HK, still here exploring :-)
>>> 
>>> Sent from my really tiny device...
>>> 
>>>> On Nov 11, 2013, at 10:17 PM, "Monty Taylor"  wrote:
>>>> 
>>>> Ok. Cool. Let's just put an upper bound on it for now then (mainly
>>>> because it's listed as 0.1, so that version to me suggests that it might
>>>> still have breaking API churn)
>>>> 
>>>>> On 11/11/2013 07:53 AM, Joshua Harlow wrote:
>>>>> I can put an upper bound on the version, that's fine with me. I'd rather 
>>>>> not avoid adding taskflow to wait until some new preemptive gating 
>>>>> process is in place. That doesn't exactly feel fair to the people 
>>>>> creating taskflow or the people using it, especially since people are 
>>>>> integrating it at this moment and it would be sad for their work to be 
>>>>> lost due to a requirement line.
>>>>> 
>>>>> As for part of oslo, cc'ing Doug since from my talks with him seem to be 
>>>>> that it's just a library and to encourage the growth of useful libraries 
>>>>> the red tape isn't needed (aka, taskflow has no strong ties to oslo and 
>>>>> I'm not sure it should).
>>>>> 
>>>>> Sent from my really tiny device...
>>>>> 
>>>>>> On Nov 11, 2013, at 7:33 PM, "Monty Taylor"  wrote:
>>>>>> 
>>>>>> There is a change up to add taskflow to the global requirements. I have
>>>>>> no problem with this in principle, but it's one more that's in the set
>>>>>> of things like pecan, wsme and friends that are in the set of things
>>>>>> that Sean talked about in preemptively gate the universe.
>>>>>> 
>>>>>> I'd like to not add it until we have a plan for at least assymetrical
>>>>>> gating, so that changes to taskflow at least can't break cinder and 
>>>>>> friends.
>>>>>> 
>>>>>> Further, I think we might need to discuss how to include libraries such
>>>>>> as this. Should taskflow be a part of oslo?
>>> 
>>> ___
>>> OpenStack-Infra mailing list
>>> OpenStack-Infra@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>> 
>> 
>> 
>> -- 
>> Robert Collins 
>> Distinguished Technologist
>> HP Converged Cloud

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] [openstack-dev] Intermittent failures cloning noVNC from github.com/kanaka

[Joshua Harlow]

https://status.github.com/messages

* 'GitHub.com is operating normally, despite an ongoing DDoS attack. The 
mitigations we have in place are proving effective in protecting us and we're 
hopeful that we've got this one resolved.'

If you were cloning from github.org and not http://git.openstack.org then you 
were likely seeing some of the DDoS attack in action.

From: Sukhdev Kapur mailto:sukhdevka...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-...@lists.openstack.org>>
Date: Tuesday, March 11, 2014 at 4:08 PM
To: "Dane Leblanc (leblancd)" mailto:lebla...@cisco.com>>
Cc: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-...@lists.openstack.org>>, 
"openstack-infra@lists.openstack.org"
 
mailto:openstack-infra@lists.openstack.org>>
Subject: Re: [openstack-dev] [OpenStack-Infra] Intermittent failures cloning 
noVNC from github.com/kanaka

I have noticed that even clone of devstack has failed few times within last 
couple of hours - it was running fairly smooth so far.

-Sukhdev



On Tue, Mar 11, 2014 at 5:05 PM, Sukhdev Kapur 
mailto:sukhdevka...@gmail.com>> wrote:
[adding openstack-dev list as well ]

I have noticed that this has stated hitting my builds within last few hours. I 
have noticed exact same failures on almost 10 builds.
Looks like something has happened within last few hours - perhaps the load?

-Sukhdev



On Tue, Mar 11, 2014 at 4:28 PM, Dane Leblanc (leblancd) 
mailto:lebla...@cisco.com>> wrote:
Apologies if this is the wrong audience for this question…

I’m seeing intermittent failures running stack.sh whereby ‘git clone 
https://github.com/kanaka/noVNC.git /opt/stack/noVNC’ is returning various 
errors.  Below are 2 examples.

Is this a known issue? Are there any localrc settings which might help here?

Example 1:

2014-03-11 15:00:33.779 | + is_service_enabled n-novnc
2014-03-11 15:00:33.780 | + return 0
2014-03-11 15:00:33.781 | ++ trueorfalse False
2014-03-11 15:00:33.782 | + NOVNC_FROM_PACKAGE=False
2014-03-11 15:00:33.783 | + '[' False = True ']'
2014-03-11 15:00:33.784 | + NOVNC_WEB_DIR=/opt/stack/noVNC
2014-03-11 15:00:33.785 | + git_clone https://github.com/kanaka/noVNC.git 
/opt/stack/noVNC master
2014-03-11 15:00:33.786 | + GIT_REMOTE=https://github.com/kanaka/noVNC.git
2014-03-11 15:00:33.788 | + GIT_DEST=/opt/stack/noVNC
2014-03-11 15:00:33.789 | + GIT_REF=master
2014-03-11 15:00:33.790 | ++ trueorfalse False False
2014-03-11 15:00:33.791 | + RECLONE=False
2014-03-11 15:00:33.792 | + [[ False = \T\r\u\e ]]
2014-03-11 15:00:33.793 | + echo master
2014-03-11 15:00:33.794 | + egrep -q '^refs'
2014-03-11 15:00:33.795 | + [[ ! -d /opt/stack/noVNC ]]
2014-03-11 15:00:33.796 | + [[ False = \T\r\u\e ]]
2014-03-11 15:00:33.797 | + git_timed clone https://github.com/kanaka/noVNC.git 
/opt/stack/noVNC
2014-03-11 15:00:33.798 | + local count=0
2014-03-11 15:00:33.799 | + local timeout=0
2014-03-11 15:00:33.801 | + [[ -n 0 ]]
2014-03-11 15:00:33.802 | + timeout=0
2014-03-11 15:00:33.803 | + timeout -s SIGINT 0 git clone 
https://github.com/kanaka/noVNC.git /opt/stack/noVNC
2014-03-11 15:00:33.804 | Cloning into '/opt/stack/noVNC'...
2014-03-11 15:03:13.694 | error: RPC failed; result=56, HTTP code = 200
2014-03-11 15:03:13.695 | fatal: The remote end hung up unexpectedly
2014-03-11 15:03:13.697 | fatal: early EOF
2014-03-11 15:03:13.698 | fatal: index-pack failed
2014-03-11 15:03:13.699 | + [[ 128 -ne 124 ]]
2014-03-11 15:03:13.700 | + die 596 'git call failed: [git clone' 
https://github.com/kanaka/noVNC.git '/opt/stack/noVNC]'
2014-03-11 15:03:13.701 | + local exitcode=0
2014-03-11 15:03:13.702 | [Call Trace]
2014-03-11 15:03:13.703 | ./stack.sh:736:install_nova
2014-03-11 15:03:13.705 | /var/lib/jenkins/devstack/lib/nova:618:git_clone
2014-03-11 15:03:13.706 | 
/var/lib/jenkins/devstack/functions-common:543:git_timed
2014-03-11 15:03:13.707 | /var/lib/jenkins/devstack/functions-common:596:die
2014-03-11 15:03:13.708 | [ERROR] 
/var/lib/jenkins/devstack/functions-common:596 git call failed: [git clone 
https://github.com/kanaka/noVNC.git /opt/stack/noVNC]


Example 2:


2014-03-11 14:12:58.472 | + is_service_enabled n-novnc

2014-03-11 14:12:58.473 | + return 0

2014-03-11 14:12:58.474 | ++ trueorfalse False

2014-03-11 14:12:58.475 | + NOVNC_FROM_PACKAGE=False

2014-03-11 14:12:58.476 | + '[' False = True ']'

2014-03-11 14:12:58.477 | + NOVNC_WEB_DIR=/opt/stack/noVNC

2014-03-11 14:12:58.478 | + git_clone https://github.com/kanaka/noVNC.git 
/opt/stack/noVNC master

2014-03-11 14:12:58.479 | + GIT_REMOTE=https://github.com/kanaka/noVNC.git

2014-03-11 14:12:58.480 | + GIT_DEST=/opt/stack/noVNC

2014-03-11 14:12:58.481 | + GIT_REF=master

2014-03-11 14:12:58.482 | ++ trueorfalse False False

2014-03-11 14:12:58.483 | + RECLONE=False

2014-03-11 14:12:58.484 | + [[ False = \T\r\u\e ]]

2014-03-11 14:12:58.485 | + echo master

2014-03-11 14:12:58.486 | + 

Re: [OpenStack-Infra] [openstack-dev] Announcing Gertty 1.0.0: A console interface to Gerrit

[Joshua Harlow]

Congrats to making it to 1.0!

May there be many more :)

Sent from my really tiny device...

> On Sep 4, 2014, at 4:18 PM, "James E. Blair"  wrote:
> 
> Announcing Gertty 1.0.0
> 
> Gertty is a console-based interface to the Gerrit Code Review system.
> 
> If that doesn't sound interesting to you, then just skip right on to
> the next message.  This mailing list gets a lot of traffic, and it's
> going to take you a while to read it all in that web browser you're
> using.
> 
> Gertty was written by and for coremudgeons.  But it's not just because
> we think mutt is the apex of user interface design.
> 
> We write code in a terminal.  We read logs in a terminal.  We debug code
> in a terminal.  We commit in a terminal.  You know what's next.
> 
> This is why I wrote Gertty:
> 
> * Workflow -- the interface is designed to support a workflow similar
>   to reading network news or mail.  In particular, it is designed to
>   deal with a large number of review requests across a large number
>   of projects.
> 
> * Offline Use -- Gertty syncs information about changes in subscribed
>   projects to a local database and local git repos.  All review
>   operations are performed against that database and then synced back
>   to Gerrit.
> 
> * Speed -- user actions modify locally cached content and need not
>   wait for server interaction.
> 
> * Convenience -- because Gertty downloads all changes to local git
>   repos, a single command instructs it to checkout a change into that
>   repo for detailed examination or testing of larger changes.
> 
> * Information Architecture -- in a console environment, Gertty can
>   display information to reviewers in a more compact and relevant
>   way.
> 
> * Colors -- I think ANSI escape sequences are a neat idea.
> 
> Here are some reasons you may want to use Gertty:
> 
> * Single page diff -- when you look at a diff, all of the files are
>   displayed on the same screen making it easier to see the full
>   context of a change as you scroll effortlessly around the files
>   that comprise it.  This may be the most requested feature in
>   Gerrit.  It was harder to make Gertty show only only one file than
>   it was to do all of them so that's what we have.  You still get the
>   choice of side-by-side or unified diff, color coding, inline
>   comments, and intra-line diffs.
> 
> * The checkout and cherry-pick commands -- Gertty works directly on
>   your local git repos, even the same ones you hack on.  It doesn't
>   change them unless you ask it to, so normally you don't notice it's
>   there, but with a simple command you can tell Gertty to check out a
>   change into your working tree, or cherry-pick a bunch of changes
>   onto a branch to build up a new patch series.  It's like "git
>   review -d" if you've ever used it, but instead of typing "git
>   review -d what-was-that-change-number-again?" you type "c".
> 
> * Your home address is seat 7A (or especially if it's 1A) -- Gertty
>   works seamlessly online or offline so you can review changes while
>   you're flying to your 15th mid-cycle meetup.  Gertty syncs all of
>   the open changes for subscribed projects to a local database and
>   performs all of its operations there.  When it's able to connect to
>   Gerrit, it uploads your reviews instantly.  When it's unable, they
>   are queued for the next time you are online.  It handles the
>   transition between online and offline effortlessly.  If your
>   Internet connection is slow or unreliable, Gertty helps with that
>   too.
> 
> * You review a lot of changes -- Gertty is fast.  All of the typical
>   review operations are performed against the local database or the
>   local git repos.  Gertty can review changes as fast as you can.  It
>   has commands to instantly navigate from change to change, and
>   shortcuts to leave votes on a change with a single keypress.
> 
> * You are particular about the changes you review -- Gertty lets you
>   subscribe to projects, and then displays each of those projects
>   along with the number of open changes and changes you have not
>   reviewed.  Open up those projects like you would a newsgroup or
>   email folder, and scroll down the list of changes.  If you don't
>   have anything to say about a change but want to see it again the
>   next time it's updated, just hit a key to mark it reviewed.  If you
>   don't want to see a change ever again, hit a different key to kill
>   it.  Gertty helps you review all of the changes you want to review,
>   and none of the changes you don't.
> 
> * Radical customization -- The queries that Gertty uses by default
>   can be customized.  It uses the same search syntax as Gerrit and
>   support most of its operators.  It has user-defined dashboards that
>   can be bound to any key.  In fact, any command can be bound to any
>   key.  The color palette can be customized.  You spend a lot of time
>   reviewing changes, you should be comfortable.
> 
> * Your terminal is an actual terminal -- Ge

Re: [OpenStack-Infra] [openstack-dev] There is no Jenkins, only Zuul

[Joshua Harlow]

James E. Blair wrote:

Since its inception, the OpenStack project has used Jenkins to perform
its testing and artifact building.  When OpenStack was two git repos,
we had one Jenkins master, a few slaves, and we configured all of our
jobs manually in the web interface.  It was easy for a new project
like OpenStack to set up and maintain.  Over the years, we have grown
significantly, with over 1,200 git repos and 8,000 jobs spread across
8 Jenkins masters and 800 dynamic slave nodes.  Long before we got to
this point, we could not manage all of those jobs by hand, so we wrote
Jenkins Job Builder[1], one of our more widely used projects, so that
we could automatically generate those 8,000 jobs from templated YAML.

We also wrote Zuul[2].

Zuul is a system to drive project automation.  It directs our testing,
running tens of thousands of jobs each day, responding to events from
our code review system and stacking potential changes to be tested
together.

We are working on a new version of Zuul (version 3) with some major
changes: we want to make it easier to run jobs in multi-node
environments, easier to manage large numbers of jobs and job
variations, support in-tree job configuration, and the ability to define
jobs using Ansible[3].


Is the goal/idea that there would be something like a '.travis.yml' 
(file or directory) that would contain the job configuration (and any 
special jobs or commands or tasks) in the project repository that zuul 
would then use and do things with (thus becoming more distributed, and 
self-configurable and more like travis CI than what previously existed)?




With Zuul in charge of deciding which jobs to run, and when and where
to run them, we use very few advanced features of Jenkins at this
point.  While we are still working on Zuul v3, we are at a point where
we can start to use some of the work we have done already to switch to
running our jobs entirely with Zuul.

As of today, we have turned off our last Jenkins master and all of our
automation is being run by Zuul.  It's been a great ride, and
OpenStack wouldn't be where it is today without Jenkins.  Now we're
looking forward to focusing on Zuul v3 and exploring the full
potential of project automation.

[1] http://docs.openstack.org/infra/jenkins-job-builder/
[2] http://docs.openstack.org/infra/zuul/
[3] https://www.ansible.com/

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra