Re: [openstack-dev] [sdk] Pruning core team

[Ricardo Carrillo Cruz]

Good from me, as I cannot spend cycles on reviewing code on my current
position.

Long live shade!

El vie., 10 ago. 2018 a las 14:07, Monty Taylor ()
escribió:

> Hey everybody,
>
> We have some former contributors who haven't been involved in the last
> cycle that we should prune from the roster. They're all wonderful humans
> and it would be awesome to have them back if life presented them an
> opportunity to be involved again.
>
> I'd like to propose removing Brian Curtin, Clint Byrum, David Simard,
> and Ricardo Cruz.
>
> Thoughts/concerns?
>
> Thanks!
> Monty
>
> __
> 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 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

Re: [openstack-dev] 回复： [devstack] How to start all OpenStack servicesafter restarting system?

[Ricardo Carrillo Cruz]

I believe screen is no longer the system to manage services in DevStack,
but systemd is now:

https://docs.openstack.org/devstack/latest/systemd.html

You should just use systemctl to bring up all OpenStack services.

HTH

2017-07-11 11:40 GMT+02:00 zhi :

> Hi, Abhishek.
>
> I have a question about devstack. The file "stack-screenrc" doesn't exist
> when I installed devstack successfully, why? I find all over the devstack
> directory but I can not find it. Could you give me some advice?
>
>
> Thanks
> Zhi Chang
>
> 2016-08-22 16:42 GMT+08:00 wk <304702...@qq.com>:
>
>> my scripts, runs ok:
>>
>> /usr/bin/python /usr/bin/glance-registry 
>> --config-file=/etc/glance/glance-registry.conf
>> &> glance-registry.log &
>> /usr/bin/python /usr//bin/glance-api 
>> --config-file=/etc/glance/glance-api.conf
>> &> glance-api.log &
>> /usr/bin/python /usr/bin/nova-conductor &> nova-conductor.log &
>> sg libvirtd /usr/bin/nova-compute --config-file /etc/nova/nova.conf &>
>> nova-compute.log &
>> /usr/bin/python /usr/bin/nova-compute --config-file /etc/nova/nova.conf
>> &> nova-compute.log &
>> /usr/bin/python /usr/bin/nova-cert &> nova-cert.log &
>> /usr/bin/python /usr/bin/nova-network --config-file /etc/nova/nova.conf
>> &> nova-network.log &
>> /usr/bin/python /usr/bin/nova-scheduler --config-file /etc/nova/nova.conf
>> &> nova-scheduler.log &
>> /usr/bin/python /usr/bin/nova-novncproxy --config-file
>> /etc/nova/nova.conf --web /opt/stack/noVNC &> nova-novncproxy.log &
>> /usr/bin/python /usr/bin/nova-xvpvncproxy --config-file
>> /etc/nova/nova.conf &> nova-xvpvncproxy.log &
>> /usr/bin/python /usr/bin/nova-consoleauth &> nova-consoleauth.log &
>> /usr/bin/python /usr/bin/nova-objectstore &> nova-objectstore.log &
>> /usr/bin/python /usr/bin/cinder-api --config-file /etc/cinder/cinder.conf
>> &> cinder-api.log &
>> /usr/bin/python /usr/bin/cinder-scheduler --config-file
>> /etc/cinder/cinder.conf &> cinder-scheduler.log &
>> /usr/bin/python /usr/bin/cinder-volume --config-file
>> /etc/cinder/cinder.conf &> cinder-volume.log &
>> /usr/bin/python /usr/bin/nova-api &> nova-api.log &
>> /usr/bin/python /opt/stack/keystone/bin/keystone-all --config-file
>> /etc/keystone/keystone.conf --log-config /etc/keystone/logging.conf -d
>> --debug &> keystone-all.log &
>> /usr/sbin/httpd -D FOREGROUND &> httpd.log &
>> /bin/sh /usr/bin/mysqld_safe --basedir=/usr &> mysqld_safe.log &
>> /usr/sbin/rabbitmq-server &> rabbitmq-server.log &
>>
>> /usr/bin/python /usr/bin/ceilometer &> ceilometer.log &
>> #start dashboard
>> systemctl start httpd
>>
>>
>> -- 原始邮件 --
>> *发件人:* "zhi";;
>> *发送时间:* 2016年8月18日(星期四) 下午5:33
>> *收件人:* "OpenStack Development Mailing List (not for usage questions)"<
>> openstack-dev@lists.openstack.org>;
>> *主题:* [openstack-dev] [devstack] How to start all OpenStack
>> servicesafter restarting system?
>>
>> hi, all.
>>
>> Currently, there is no "rejoin-stack.sh" script in devstack.
>>
>>  It will clear all resources and create all resources if I rerun
>> "./stack.sh" after restarting system.
>>
>>  So,  how to start all OpenStack services after restarting system
>> quickly?
>>
>>
>> Thanks
>> Zhi Chang
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> 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 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-dev] [openstack-infra][all] Status update of the InfraCloud

[Ricardo Carrillo Cruz]

Hi there

We would like to write an update about the status of the InfraCloud ( if
you never heard of it, it's essentially a bunch of hardware donated by HPE
to the project to run an OpenStack cloud for CI testing. More info at
http://docs.openstack.org/infra/system-config/infra-cloud.html ).

We decided in the last infra mid-cycle at Fort Collins to split logically
the machines given (roughly 132 servers, with a mix of SL390s, SL230s and
SE1170s) in two different clouds: vanilla and chocolate, in order to have
each cloud running the current and previous OpenStack version.

The vanilla region, which is comprised of 48 SL390s nodes, has been
provisioned with Mitaka and this is how it looks like:

1 x Bifrost machine to provision the clouds control plane
1 x Controller
42 x Computes
4 x nodes currently being investigated due to faulty HW issues

This vanilla cloud has already been enabled in Nodepool:

https://review.openstack.org/#/c/363942/

So far, it's running quite well per the Logstash job logs collected from it.

Next step is to bump the max-servers to 50 servers (
https://review.openstack.org/#/c/364101/ ) to stress it a little bit more
to eventually unlock it to its full potential.
The SL390s report 24 cores, so this region can serve as quite a big
provider for CI runs.

We are looking forward to hear from you any feedback or problems you may
encounter.
We also plan to have a track on the infra mid-cycle in two weeks to plan
the rollout of the chocolate region and overall improvements.

Regards
__
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

Re: [openstack-dev] [OpenStack-Infra] [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-in...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
__
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

Re: [openstack-dev] [all] devstack changed to neutron by default - merged

[Ricardo Carrillo Cruz]

Thanks a million for this!

Ricky

2016-08-09 13:25 GMT+02:00 Davanum Srinivas :

> Yay! Long time to get here. But we are here :)
>
> -- Dims
>
> On Tue, Aug 9, 2016 at 7:04 AM, Sean Dague  wrote:
> > https://review.openstack.org/#/c/350750/ has merged, which moves us over
> > to neutron by default in devstack.
> >
> > If you have manually set services in your local.conf, you won't see any
> > changes. If you don't regularly set those services, you'll be using
> > neutron on your next stack.sh after this change.
> >
> > The *one* major difference in configuration is that PUBLIC_INTERFACE
> > means something different with neutron. This now means the interface
> > that you would give to neutron and let it completely take over. There
> > will be docs coming soon to explain this a bit better on the devstack
> > documentation site (http://devstack.org) once I'm a few more cups of
> > coffee into the morning. However, in the mean time, if you see weird
> > fails during stacking, try deleting PUBLIC_INTERFACE from your
> local.conf.
> >
> > -Sean
> >
> > --
> > Sean Dague
> > http://dague.net
> >
> > 
> __
> > 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
>
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> 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 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-dev] [designate][ansible] Ansible OpenStack modules for Designate available

[Ricardo Carrillo Cruz]

Hi there

I'm happy to report that modules to manage Designate zones and recordsets
have landed on Ansible extras devel branch:

https://github.com/ansible/ansible-modules-extras/blob/devel/cloud/openstack/os_zone.py
https://github.com/ansible/ansible-modules-extras/blob/devel/cloud/openstack/os_recordset.py

If you find issues, please reach me out on IRC (rcarrillocruz) and/or open
an issue on GitHub:

https://github.com/ansible/ansible-modules-extras/issues

Also, if you have interest on having other Designate resources implemented
as Ansible modules let me know,
as I'm now looking for new streams of work on Ansible land.

Thanks
__
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

Re: [openstack-dev] [TripleO] Making TripleO CI easier to consume outside of TripleO CI

[Ricardo Carrillo Cruz]

I concur, in infra we install roles from git repos.
Those are defined in a yaml that are then feeded to ansible-galaxy tool:

http://git.openstack.org/cgit/openstack-infra/system-config/tree/roles.yaml

Regards

2016-07-13 17:58 GMT+02:00 David Moreau Simard :

> On Wed, Jul 13, 2016 at 9:06 AM, Wesley Hayutin 
> wrote:
> > We also considered ansible-galaxy and any of the ansible roles found in
> > github/redhat-openstack/ansible-role could be moved into galaxy.  Galaxy
> did
> > not end up meeting our requirements for installing the roles and we
> ended up
> > using python setuptools.  Some roles have specific config and playbooks
> that
> > need to be copied to a standard location and galaxy just did not do that
> > very well.
>
> What special requirements do you have around that ?
> I'm able to install roles both from git (zuul-cloner) and from
> ansible-galaxy just fine.
>
> - ansible-role-requirements.yml [1]
> - ansible-galaxy install [2]
> - ansible.cfg role path [3]
>
> Stuff doesn't necessarily need to be "uploaded" to galaxy.
> ansible-galaxy is really a glorified wrapper around git :)
>
> [1]:
> https://github.com/rdo-infra/weirdo/blob/master/ansible-role-requirements.yml
> [2]: https://github.com/rdo-infra/weirdo/blob/master/tox.ini#L26
> [3]:
> https://github.com/rdo-infra/weirdo/blob/master/playbooks/ansible.cfg#L9
>
> David Moreau Simard
> Senior Software Engineer | Openstack RDO
>
> dmsimard = [irc, github, twitter]
>
> __
> 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 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

Re: [openstack-dev] [all] what do you work on upstream of OpenStack?

[Ricardo Carrillo Cruz]

Hi Doug

I've written a few Ansible OpenStack modules, for example:

https://github.com/ansible/ansible-modules-extras/pull/2240

Some pending merge, some others already merged.

Regards

2016-06-13 21:41 GMT+02:00 Doug Hellmann :

> Thanks!
>
> > On Jun 13, 2016, at 3:23 PM, Anita Kuno  wrote:
> >
> > On 06/13/2016 03:11 PM, Doug Hellmann wrote:
> >> I'm trying to pull together some information about contributions
> >> that OpenStack community members have made *upstream* of OpenStack,
> >> via code, docs, bug reports, or anything else to dependencies that
> >> we have.
> >>
> >> If you've made a contribution of that sort, I would appreciate a
> >> quick note.  Please reply off-list, there's no need to spam everyone,
> >> and I'll post the summary if folks want to see it.
> >>
> >> Thanks,
> >> Doug
> >>
> >>
> __
> >> 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
> >>
> > Upstream gerrit.
> >
> > I think it was a doc whitespace patch or comment whitespace patch. It
> > was fairly insignificant but it exists.
> >
> > Thanks for asking the question,
> > Anita.
> >
> >
> __
> > 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 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 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

Re: [openstack-dev] [neutron][devstack] State of the refactor

[Ricardo Carrillo Cruz]

Yeah, seriously, thanks a million for this.
You are making developers lives wa better!

2016-05-05 18:12 GMT+02:00 Monty Taylor :

> On 05/05/2016 10:57 AM, Sean M. Collins wrote:
>
>> During the Austin summit, there was a discussion in the QA meetings
>> about the future of Neutron's support in DevStack. It's been an ongoing
>> effort, and I'd like to step back and give everyone a view of the Big
>> Picture.
>>
>> https://etherpad.openstack.org/p/newton-qa-devstack-roadmap
>>
>> A year ago at the NYC QA midcycle, consensus was reached that in order
>> to get Neutron to become the default deployment model for Devstack and
>> finally deprecate Nova-Network, some grunt work would need to be done to
>> clean up the DevStack code.
>>
>> Dean wrote about the experience in his blog:
>>
>> http://hackstack.org/x/blog/2015/03/30/qa-code-sprint
>>
>> DevStack's Neutron code is in bad shape. It has been continually
>>> updated by many people who do not understand the Big Picture. I blame
>>> myself for not staying on top of this code and allowing it to diverge
>>> from the rest of DevStack's style and implementation. Other Sean found
>>> a number of inconsistencies in variable names and uses as he tried to
>>> get the single interface work done and we came to the inevitable
>>> conclusion that it was time to start over.
>>>
>>
>> So we did.
>>
>> https://review.openstack.org/168438
>>
>> The new lib/neutron is an attempt to only have the *bare minimum*
>> configured for either an OVS or Linux Bridge deployment of Neutron. My
>> strategy was - start from scratch and build up enough Neutron
>> configuration to get everything to launch, and have the network plumbed
>> correctly. Everything else was left on the cutting room floor.
>>
>> There are still some things that I did for the sake of expediency, that
>> I am sure will need to be improved in the future. However, the code is
>> very close to completion - there's still some work that needs to be
>> done, but I see the light at the end of the tunnel.
>>
>> For anything that isn't ML2 based, or the LB or OVS agent, Dean and I
>> share this view:
>>
>> But what about the plugins? What about the advanced services? What
>>> about the vendors? I can't do it all at once. The first priority is to
>>> get a 'minimum viable Neutron' configuration to use as the default.
>>> The old code was renamed not removed, and exactly zero of the
>>> configuration variables and service names have changed. Nothing should
>>> be directly importing lib/neutron* so that change is handled in
>>> DevStack and Grenade already. After we have working linuxbridge and
>>> ovs configurations we can look at what else needs to be included.
>>>
>>
>> Sean Dague and I have also been kicking around some ideas about adding
>> another hook to the DevStack plugin contract so that DevStack plugins
>> that do network things have a chance to create networks and wire
>> everything during installation and configuration, as part of a DevStack
>> plugin call.
>>
>> The basic reasoning for this is, the current lib/neutron-legacy has tons
>> of knobs for plugging veths into things, creating provider networks,
>> etc.. - those things are very specific to a deployment or networking
>> type, so they should be moved into a plugin so they don't gunk up the
>> main code path and also avoid trampling one another (like they do
>> today).
>>
>> The current lib/neutron weighs in around 500 lines of code, and the l3
>> setup code (which was the nastiest) is 300 lines, split out into a
>> separate file. Partially to allow other plugins to call this code, and
>> partially because of a divide-and-conquer strategy I am employing for
>> the refactor.
>>
>> If you haven't read my post about eliminating the DevStack layer, this
>> is also part of my thought process for the refactor, and how to support
>> other configurations in DevStack.
>>
>> http://lists.openstack.org/pipermail/openstack-dev/2016-April/091764.html
>>
>> So, take a look at what I've done so far, take it for a spin, and if you
>> have any thoughts or ideas please share them!
>>
>
> Everything about this is the best thing that has ever happened since the
> dawn of time.
>
>
>
> __
> 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 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

Re: [openstack-dev] [all][stackalytics] Gaming the Stackalytics stats

[Ricardo Carrillo Cruz]

++, exactly my thoughts.

I believe most people don't vote 0 for questions about the change because
'it won't count'.
That's really bad, IMHO 0 should be for asking things not clear in the
patch, whereas a -1 should be a 'this code here is not right'.

I believe the 0s should be tracked somehow.

Regards

2016-04-10 18:08 GMT+02:00 Joshua Harlow :

> +1 from me also,
>
> I also use +0 for question asking and the like, because IMHO that's not
> what -1 are for. As for myself losing stackalytics stats when *I* do this
> (ie using +0 instead of -1), meh, I got better things in my life to
> think/care about :-P
>
> -Josh
>
>
> Nikhil Komawar wrote:
>
>> Thanks Amrith!
>>
>> I am a big supporter on including +0s.
>>
>> On 4/9/16 6:31 PM, Amrith Kumar wrote:
>>
>>> Thanks to Dims and Steve for bringing this up.
>>>
>>> It has long been my opinion that +0's are invaluable for the
>>> question asking, and for getting to understand software, and unfortunately
>>> +0's are lost in the noise. So a while ago, I posted to the ML [1] asking
>>> about making +0's more visible. I signed up to submit a request on gerrit
>>> upstream (and promptly forgot to do that). This mail thread has reminded me
>>> of that. I have now posted a request for the upstream gerrit folks to fix
>>> [2].
>>>
>>> I believe that people don't use +0's enough because they often
>>> get ignored. I know that one can be cynical and say it is because it gives
>>> one no credit in stackalytics; I choose not to be that person.
>>>
>>> I post +0's a lot. But, I find that they are often ignored. If
>>> you agree with me that +0's are useful, and could be highlighted better in
>>> the gerrit review screen, please post a comment on [2].
>>>
>>> Thanks,
>>>
>>> -amrith
>>>
>>> [1] http://openstack.markmail.org/thread/nj4onttaibjmfxew
>>> [2] https://code.google.com/p/gerrit/issues/detail?id=4050
>>>
>>> -Original Message-
 From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com]
 Sent: Saturday, April 09, 2016 9:43 AM
 To: openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [all][stackalytics] Gaming the Stackalytics
 stats



 On 4/8/2016 5:54 PM, Jay Faulkner wrote:

> I know a lot of folks explicitly avoid a +0 vote with a comment
> because you don't get "credit" for it in statistics. Whether or not
> that should matter is another discussion, but there is a significant
> disincentive to no-voting right now.
>
>
> -
>
> Jay Faulkner
>
>
>
> --
> --
> *From:* Dolph Mathews
> *Sent:* Friday, April 8, 2016 1:54 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [all][stackalytics] Gaming the
> Stackalytics stats
>
>
> On Friday, April 8, 2016, John Dickinson >
> wrote:
>
>
>
>  On 8 Apr 2016, at 13:35, Jeremy Stanley wrote:
>
>   >  On 2016-04-08 19:42:18 +0200 (+0200), Dmitry Tantsur wrote:
>   >>  There are many ways to game a simple +1 counter, such as
> +1'ing
>  changes
>   >>  that already have at least 1x +2, or which already approved,
> or
>  which need
>   >>  rechecking...
>   >  [...]
>   >
>   >  The behavior which baffles me, and also seems to be on the
> rise
>   >  lately, is random +1 votes on changes whose commit messages
>
 and/or

>   >  status clearly indicate they should not merged and do not
> need to
>
 be

>   >  reviewed. I suppose that's another an easy way to avoid the
>
 dreaded

>   >  "disagreements" counter?
>   >  --
>   >  Jeremy Stanley
>
>
>  I have been told that some OpenStack on boarding teaches new
> members
>  of the community to do reviews. And they say, effectively, "muddle
>  through as you can. You won't understand it all at first, but do
>  your best. When you're done, add a +1 and move to the next one"
>
>
> I advocate for basically this, but instead of a +1, leave a +0 and ask
> questions. The new reviewer will inevitably learn something and the
> author will benefit by explaining their change (teaching is the best
> way to learn).
>
>
>  I've been working to correct this when I've seen it, but +1
> reviews
>  with no comments might not be people trying to game. It might
> simply
>  be people trying to get involved that don't know any better yet.
>
>  --John
>
>
>
>
>
> __
>  OpenStack Development Mailing List (not for usage 

Re: [openstack-dev] [ironic] Nominating Julia Kreger for core reviewer

[Ricardo Carrillo Cruz]

A big +1 from me.

Just to let you know, Julia has been fundamental in helping us in infra to
review and accept patches
in Bifrost as we encountered missing features during the infra cloud
testing.

Thanks Julia!

2016-03-24 21:37 GMT+01:00 Villalovos, John L :

> +1 for me. Julia has been an awesome resource and person in the Ironic
> community :)
>
> John
>
> -Original Message-
> From: Jim Rollenhagen [mailto:j...@jimrollenhagen.com]
> Sent: Thursday, March 24, 2016 12:09
> To: openstack-dev@lists.openstack.org
> Subject: [openstack-dev] [ironic] Nominating Julia Kreger for core reviewer
>
> Hey all,
>
> I'm nominating Julia Kreger (TheJulia in IRC) for ironic-core. She runs
> the Bifrost project, gives super valuable reviews, is beginning to lead
> the boot from volume efforts, and is clearly an expert in this space.
>
> All in favor say +1 :)
>
> // jim
>
> __
> 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 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 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

Re: [openstack-dev] [all] A proposal to separate the design summit

[Ricardo Carrillo Cruz]

+1

2016-02-22 18:27 GMT+01:00 Clayton O'Neill :

> Is the expectation that the ops mid-cycle would continue separately,
> or be held with the meeting formerly known as the Design Summit?
>
> Personally I’d prefer they be held together, but scheduled with the
> thought that operators aren’t likely to be interested in work
> sessions, but that a good number of us would be interested in
> cross-project and some project specific planning sessions.  This would
> also open up the possibility of having some sessions specific intended
> for operator/developer feedback sessions.
>
> On Mon, Feb 22, 2016 at 12:15 PM, Lauren Sell 
> wrote:
> >
> >> On Feb 22, 2016, at 8:52 AM, Clayton O'Neill 
> wrote:
> >>
> >> I think this is a great proposal, but like Matt I’m curious how it
> >> might impact the operator sessions that have been part of the Design
> >> Summit and the Operators Mid-Cycle.
> >>
> >> As an operator I got a lot out of the cross-project designs sessions
> >> in Tokyo, but they were scheduled at the same time as the Operator
> >> sessions.  On the other hand, the work sessions clearly aren’t as
> >> useful to me.  It would be nice would be worked out so that the new
> >> design summit replacement was in the same location, and scheduled so
> >> that the operator specific parts were overlapping the work sessions
> >> instead of the more big picture sessions.
> >
> > Great question. The current plan is to maintain the ops summit and
> mid-cycle activities.
> >
> > The new format would allow us to reduce overlap between ops summit and
> cross project sessions at the main event, both for the operators and
> developers who want to be involved in either activity.
>
> __
> 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 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

Re: [openstack-dev] [kolla][infra] Publishing kolla images to docker-registry.openstack.org

[Ricardo Carrillo Cruz]

Hi Steve

When you say the registry would require a machine with plenty of disk
space, do you have an estimate of storage needed?

Regards

2016-02-20 14:21 GMT+01:00 Steven Dake (stdake) :

> Infra folks,
>
> I'd like to see a full CI/CD pipeline of Kolla to an OpenStack
> infrastructure hosted registry.
>
> With docker registry 2.2 and earlier a Docker push of Kolla containers
> took 5-10 hours.  This is because of design problems in Docker which made a
> push each layer of each Docker image repeatedly.  This has been rectified
> in docker-regitery 2.3 (the latest hub tagged docker registry).  The 5-10
> hour upload times are now down to about 15 minutes.  Now it takes
> approximately 15 minutes to push all 115 kolla containers on a gigabit
> network.
>
> Kolla in general wants to publish to a docker registry at least per tag,
> and possibly per commit (or alternatively daily).  We already build Kolla
> images in the gate, and although sometimes our jobs time out on CentOS the
> build on Ubuntu is about 12 minutes.  The reason our jobs time out on
> CentOS is because we lack local to the infrastructure mirrors as is
> available on Ubuntu from a recent patch I believe that Monty offered.
>
> We have one of two options going forward
>
>1. We could publish to the docker hub registry
>2. We could publish to docker-registry.openstack.org
>
> Having a docker-registry.openstack.org would be my preference, but
> requires a machine with plenty of disk space and a copy of docker 1.10.1 or
> later running on it.  The docker-registry 2.3 and later runs as a container
> inside Docker.  The machine could be Ubuntu or CentOS – we have gate
> scripts for both that do the machine setup which the infrastructure team
> could begin with[1][2]  I don't care which distro is used for docker
> registry – it reallly shouldn't matter as it will be super lightweight and
> really only need a /var/lib/docker that is fast and large.  Kolla dev's can
> help get the docker registry setup and provide guidance to the
> infrastructure team on how to setup Docker, but I'm unclear of OpenStack
> has resources to make this particular request happen.
>
> NB the machine need not be baremetal – it  really doesn't matter.  It does
> need fast bi-directional networking and fast disk IO to meet the gate
> timeout requirements and Operator requirements that a pull is speedy.  The
> other change needed is a CentOS mirror internal to the infrastructure, so
> our CentOS jobs don't time out and we can push per cmmit (or we could add a
> nightly job).
>
> This is something new OpenStack hasn't done before, so feedback from the
> infrastructure team welcome if that team is willing to maintain a
> docker-registry.openstack.org.  The other challenge here will be
> authentication – we setup our gate Docker without TLS because we throw away
> the VMs but infra will want to setup TLS with the docker registry.  Folks
> wanting to use the docker reigstry service from OpenStack will need to be
> able to put TLS credentials in the gating in some way.  I'm not sure we
> want to just check these credentials into our repository – which means they
> need to somehow be injected into our VMs to protect the security of the
> Docker images.
>
> If infra decides they don’t want to take on a
> docker-registry.openstack.org, guidance on how to get our credentials
> securely into our built VM would be helpful.
>
> One final note – Docker can be setup to use Swift as a storage backend, or
> alternatively can use straight up disk space on the node.  It can also
> publish to an AWS storage backend and has many other storage backend modes.
>
> Regards
> -steve
>
>
> [1] https://github.com/openstack/kolla/blob/master/tools/setup_RedHat.sh
> [2] https://github.com/openstack/kolla/blob/master/tools/setup_Debian.sh
>
> __
> 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 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

Re: [openstack-dev] I love csv output in openstackclient, please never removed it

[Ricardo Carrillo Cruz]

Erm, yeah, I hear your pain with processing output with awk.

Having the option to output CSV is cool :-).
Thanks for sharing.

Cheers

2015-10-02 21:49 GMT+02:00 Thomas Goirand :

> Hi,
>
> I saw the csv output format of openstackclient going and coming back.
> Please leave it in, it's super useful, especially when you combine it
> with "q-text-as-data". Just try to apt-get install q-text-as-data" and
> try by yourself:
>
> openstack endpoint list --long -f csv | \
> q -d , -H 'SELECT ID FROM - WHERE `Service Name`="cinder"'
>
> This is so much better than any awk hacks to get IDs... :)
> I just wanted to share, hoping it could be useful to someone.
>
> Cheers,
>
> Thomas Goirand (zigo)
>
> __
> 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 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

Re: [openstack-dev] [Ansible][Infra] Moving ansible roles into big tent?

[Ricardo Carrillo Cruz]

I'm interested in ansible roles for openstack-infra, but as there is
overlap in functionality
with the current openstack-infra puppet roles I'm not sure what's the
stance from the
openstack-infra core members and PTL.

I think they should go to openstack-infra, since Nodepoo/Zuul/etc are very
specific
to the OpenStack CI.

Question is if we should have a subgroup within openstack-infra namespace
for
'stuff that is not used by OpenStack CI but interesting from CI perspective
and/or
used by other downstream groups'.

Regards

2015-09-09 19:22 GMT+02:00 Paul Belanger :

> On Tue, Sep 08, 2015 at 06:50:38PM -0400, Emilien Macchi wrote:
> >
> >
> > On 09/08/2015 10:57 AM, Paul Belanger wrote:
> > > Greetings,
> > >
> > > I wanted to start a discussion about the future of ansible / ansible
> roles in
> > > OpenStack. Over the last week or so I've started down the ansible
> path, starting
> > > my first ansible role; I've started with ansible-role-nodepool[1].
> > >
> > > My initial question is simple, now that big tent is upon us, I would
> like
> > > some way to include ansible roles into the opentack git workflow.  I
> first
> > > thought the role might live under openstack-infra however I am not
> sure that
> > > is the right place.  My reason is, -infra tents to include modules they
> > > currently run under the -infra namespace, and I don't want to start
> the effort
> > > to convince people to migrate.
> >
> > I'm wondering what would be the goal of ansible-role-nodepool and what
> > it would orchestrate exactly. I did not find README that explains it,
> > and digging into the code makes me think you try to prepare nodepool
> > images but I don't exactly see why.
> >
> > Since we already have puppet-nodepool, I'm curious about the purpose of
> > this role.
> > IMHO, if we had to add such a new repo, it would be under
> > openstack-infra namespace, to be consistent with other repos
> > (puppet-nodepool, etc).
> >
> > > Another thought might be to reach out to the os-ansible-deployment
> team and ask
> > > how they see roles in OpenStack moving foward (mostly the reason for
> this
> > > email).
> >
> > os-ansible-deployment aims to setup OpenStack services in containers
> > (LXC). I don't see relation between os-ansible-deployment (openstack
> > deployment related) and ansible-role-nodepool (infra related).
> >
> > > Either way, I would be interested in feedback on moving forward on
> this. Using
> > > travis-ci and github works but OpenStack workflow is much better.
> > >
> > > [1] https://github.com/pabelanger/ansible-role-nodepool
> > >
> >
> > To me, it's unclear how and why we are going to use
> ansible-role-nodepool.
> > Could you explain with use-case?
> >
> The most basic use case is managing nodepool using ansible, for the
> purpose of
> CI.  Bascially, rewrite puppet-nodepool using ansible.  I won't go into the
> reasoning for that, except to say people do not want to use puppet.
>
> Regarding os-ansible-deployment, they are only related due to both using
> ansible. I wouldn't see os-ansible-deployment using the module, however I
> would
> hope to learn best practices and code reviews from the team.
>
> Where ever the module lives, I would hope people interested in ansible
> development would be group somehow.
>
> > Thanks,
> > --
> > Emilien Macchi
> >
> >
> __
> > 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 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 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

Re: [openstack-dev] [OpenStack-Infra] Need help! Zuul can not connect to port 29418 of review.openstack.org

[Ricardo Carrillo Cruz]

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 t...@openstack.org:

 On 12/06/15 17:04, liuxinguo wrote:

 Hi,

 Recentlyour CI can not connect to port 29418 of
 review.openstack.org.app:ds:recently

 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-in...@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

__
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

Re: [openstack-dev] [infra][third-party] Common-CI Virtual Sprint

[Ricardo Carrillo Cruz]

Whenever is, I'll participate.

Regards

2015-06-04 21:09 GMT+02:00 Spencer Krum n...@spencerkrum.com:

 I'm in!

 --
   Spencer Krum
   n...@spencerkrum.com

 On Thu, Jun 4, 2015, at 09:22 AM, Asselin, Ramy wrote:
  Hi,
 
  It was nice to meet many of you at the Vancouver Infra Working Session.
  Quite a bit of progress was made finding owners for some of the common-ci
  refactoring work [1] and puppet testing work. A few patches were
  proposed, reviewed, and some merged!
 
  As we continue the effort over the coming weeks, I thought it would be
  helpful to schedule a  virtual sprint to complete the remaining tasks.
 
  GOAL: By the end of the sprint, we should be able to set up a 3rd party
  CI system using the same puppet components that the OpenStack
  infrastructure team is using in its production CI system.
 
  I proposed this in Tuesday's Infra meeting [1] there was general
  consensus that this would be valuable (if clear goals are documented) and
  that July 8  9 are good dates. (After the US  Canada July 1st and 4th
  holidays, not on Tuesday, and not near a Liberty Milestone)
 
  I would like to get comments from a broader audience on the goals and
  dates.
 
  You can show interest by adding your name to the etherpad [3].
 
  Thank you,
  Ramy
  irc: asselin
 
 
 
  [1]
 
 http://specs.openstack.org/openstack-infra/infra-specs/specs/openstackci.html
  [2]
 
 http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-06-02-19.01.html
  [3] https://etherpad.openstack.org/p/common-ci-sprint
 
 
 
 
 __
  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 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 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

Re: [openstack-dev] [infra] [storyboard] Nominating Yolanda Robla for StoryBoard Core

[Ricardo Carrillo Cruz]

Big +1 from me :-).

Yolanda is an amazing engineer, both frontend and backend.
As Michael said, she's not only been doing Storyboard but a bunch of other
infra stuff that will be beneficial for the project.

Regards!

2014-12-24 0:38 GMT+01:00 Zaro zaro0...@gmail.com:

 +1

 On Tue, Dec 23, 2014 at 2:34 PM, Michael Krotscheck krotsch...@gmail.com
 wrote:

 Hello everyone!

 StoryBoard is the much anticipated successor to Launchpad, and is a
 component of the Infrastructure Program. The storyboard-core group is
 intended to be a superset of the infra-core group, with additional
 reviewers who specialize in the field.

 Yolanda has been working on StoryBoard ever since the Atlanta Summit, and
 has provided a diligent and cautious voice to our development effort. She
 has consistently provided feedback on our reviews, and is neither afraid of
 asking for clarification, nor of providing constructive criticism. In
 return, she has been nothing but gracious and responsive when improvements
 were suggested to her own submissions.

 Furthermore, Yolanda has been quite active in the infrastructure team as
 a whole, and provides valuable context for us in the greater realm of infra.

 Please respond within this thread with either supporting commentary, or
 concerns about her promotion. Since many western countries are currently
 celebrating holidays, the review period will remain open until January 9th.
 If the consensus is positive, we will promote her then!

 Thanks,

 Michael


 References:

 https://review.openstack.org/#/q/reviewer:%22yolanda.robla+%253Cinfo%2540ysoft.biz%253E%22,n,z

 http://stackalytics.com/?user_id=yolanda.roblametric=marks


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



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


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

Re: [openstack-dev] [Infra][all] Synchronizing local Git and Gerrit repositories

[Ricardo Carrillo Cruz]

Code review is a vital part of the Openstack CI workflow, and as such the
git repos managed by Openstack CI Gerrit are the authorative sources.

It looks to me you don't want to have Gerrit to be the authorative git
server to avoid doing code reviews in experiments or to share code among
developers, but going down that route will put you in a
situation hard to maintain, as Dolph alredy mentioned.

I recommend you follow the same layout as upstream (Gerrit being the
authorative git server with other git servers mirroring it) and you install
something like GitLab to have your developers make experiments and long
lived branches that they do not want to go thru code review for sharing.

Regards

2014-10-29 22:43 GMT+01:00 Stefano Maffulli stef...@openstack.org:

 On 10/29/2014 07:02 AM, Ondrej Wisniewski wrote:
  If I understand correctly, we cannot use the OpenStack community Git
  servers as our central Git repository since developers cannot push to
  them. And we don't want to go through Gerrit and the code review
  procedure just to share a bit of code with somebody else in the team.
  Thus the need for a local mirror.

 I have been having similar questions as Dolph. Are you going to Paris by
 chance? It'd be great to have a chat in person and understand exactly
 your needs.

  Additionally also a local Gerrit server was set up to allow for internal
  code review within the team before submitting anything to the community
  server review.openstack.org http://review.openstack.org (which will be
  done eventually).

 As Dolph mentioned, you may be able to use review.openstack.org for
 that, keeping the patches as Work In Progress (workflow-1): your
 developers can all participate in the reviews and mark the change as
 'Ready for review' when ready. This will allow you to stay close to
 trunk and avoid complex setup on your side. It also allows your
 developers to participate more in the 'openstack way' of doing things,
 maybe even do some code reviews for other patches while they're on
 review.openstack.org, it's less likely that your team will show up with
 a large patch after a long internal conversation.

  This is also helpful in case our Internet connection
  goes down, as we will still be able to follow the complete workflow
  inside the LAN.

 Fair enough: how often does your Internet connection drop?

 /stef


 --
 Ask and answer questions on https://ask.openstack.org

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

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

Re: [openstack-dev] [Infra][all] Synchronizing local Git and Gerrit repositories

[Ricardo Carrillo Cruz]

Hi Ondrej

The replication between Gerrit and git mirrors is done by the Gerrit
replication mechanism.

If you look at this line in the gerrit manifest:

http://git.openstack.org/cgit/openstack-infra/system-config/tree/modules/gerrit/manifests/init.pp#n255

you will see that it deploys a 'replication.config' file based on template:

http://git.openstack.org/cgit/openstack-infra/system-config/tree/modules/gerrit/templates/replication.config.erb

You can find more information about how Gerrit replication works here:

http://gerrit.googlecode.com/svn/documentation/2.0/config-replication.html

HTH

Regards

2014-10-24 18:25 GMT+02:00 Ondrej Wisniewski 
ondrej.wisniew...@dektech.com.au:

  Hi,

 I am trying to set up an OpenStack development workflow in our company. We
 have an internal Git repository mirror of all OpenStack projects we are
 working on. It is periodically updated from the upstream OpenStack
 community servers. This is used to share the code among developers.

 Furthermore I have set up a Gerrit server for the internal code review.
 The Gerrit server also works with repository mirrors of the community
 repositories which should be updated periodically. Or at least that's the
 idea. I ran into lots of problems and couldn't find a good way of
 synchronizing the developer mirrors with the Gerrit repositories.

 So to cut a long story short, here are my questions:
 How is the synchronization of the OpenStack community Git repositories and
 the Gerrit server done?
 How can I import an OpenStack project into my Gerrit system from my local
 Git mirror and keep both synchronized (at least the master branch) ?

 I would be really appreciate if someone could shed some light on this.
 Thanks, Ondrej

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


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

Re: [openstack-dev] [infra] Nominating Andreas Jaeger for project-config-core

[Ricardo Carrillo Cruz]

+1 from me, Andreas is very responsive and his reviews are spot on.

Regards

2014-09-26 22:11 GMT+02:00 Anne Gentle a...@openstack.org:



 On Fri, Sep 26, 2014 at 10:35 AM, James E. Blair cor...@inaugust.com
 wrote:

 I'm pleased to nominate Andreas Jaeger to the project-config core team.

 The project-config repo is a constituent of the Infrastructure Program
 and has a core team structured to be a superset of infra-core with
 additional reviewers who specialize in the area.

 Andreas has been doing an incredible amount of work simplifying the
 Jenkins and Zuul configuration for some time.  He's also been making it
 more complicated where it needs to be -- making the documentation jobs
 in particular a model of efficient re-use that is far easier to
 understand than what he replaced.  In short, he's an expert in Jenkins
 and Zuul configuration and both his patches and reviews are immensely
 helpful.


 Huge +1 - docs CI is a beautiful thing.


 Please respond with support or concerns and if the consensus is in
 favor, we will add him next week.

 Thanks,

 Jim

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



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


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

Re: [openstack-dev] [all] OpenStack bootstrapping hour - Friday Sept 19th - 3pm EST

[Ricardo Carrillo Cruz]

This is awesome, thanks for this guys!

Regards

2014-09-16 7:09 GMT+02:00 Angelo Matarazzo matarazzoang...@gmail.com:

 You are great!!!
 As newbie I tell you: thank you a lot
 Angelo
 Il giorno 16/set/2014 00:58, Sean Dague s...@dague.net ha scritto:

 A few of us have decided to pull together a regular (cadence to be
 determined) video series taking on deep dives inside of OpenStack,
 looking at code, explaining why things work that way, and fielding
 questions from anyone interested.

 For lack of a better title, I've declared it OpenStack Bootstrapping Hour.

 Episode 0 - Mock best practices will kick off this Friday, Sept 19th,
 from 3pm - 4pm EST. Our experts for this will be Jay Pipes and Dan
 Smith. It will be done as a Google Hangout on Air, which means there
 will be a live youtube stream while it's on, and a recorded youtube
 video that's publicly accessible once we're done.

 We'll be using an etherpad during the broadcast to provide links to the
 content people are looking at, as well as capture questions. That will
 be our backchannel, and audience participation forum, with the advantage
 that it creates a nice concise document at the end of the broadcast that
 pairs well with the video. (Also: the tech test showed that while code
 examples are perfectly viewable during in the final video, during the
 live stream they are a little hard to read, etherpad links will help
 people follow along at home).

 Assuming this turns out to be useful, we're thinking about lots of other
 deep dives. The intent is that these are indepth dives. We as a
 community have learned so many things over the last 4 years, but as
 OpenStack has gotten so large, being familiar with more than a narrow
 slice is hard. This is hopefully a part of the solution to address that.
 As I've told others, if nothing else, I'm looking forward to learning a
 ton in the process.

 Final links for the hangout + etherpad will be posted a little later in
 the week. Mostly wanted to make people aware it was coming.

 -Sean

 --
 Sean Dague
 http://dague.net

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


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


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

Re: [openstack-dev] [QA] Proposed Changes to Tempest Core

[Ricardo Carrillo Cruz]

Congrats Andrea, well deserved!


2014-07-25 19:37 GMT+02:00 Matthew Treinish mtrein...@kortar.org:

 So all of the current core team members have voted unanimously in favor of
 adding Andrea to the team.

 Welcome to the team Andrea.

 -Matt Treinish

 On Fri, Jul 25, 2014 at 01:32:27PM -0400, Attila Fazekas wrote:
  +1
 
 
  - Original Message -
   From: Matthew Treinish mtrein...@kortar.org
   To: openstack-dev@lists.openstack.org
   Sent: Tuesday, July 22, 2014 12:34:28 AM
   Subject: [openstack-dev] [QA] Proposed Changes to Tempest Core
  
  
   Hi Everyone,
  
   I would like to propose 2 changes to the Tempest core team:
  
   First, I'd like to nominate Andrea Fritolli to the Tempest core team.
 Over
   the
   past cycle Andrea has been steadily become more actively engaged in the
   Tempest
   community. Besides his code contributions around refactoring Tempest's
   authentication and credentials code, he has been providing reviews
 that have
   been of consistently high quality that show insight into both the
 project
   internals and it's future direction. In addition he has been active in
 the
   qa-specs repo both providing reviews and spec proposals, which has
 been very
   helpful as we've been adjusting to using the new process. Keeping in
 mind
   that
   becoming a member of the core team is about earning the trust from the
   members
   of the current core team through communication and quality reviews, not
   simply a
   matter of review numbers, I feel that Andrea will make an excellent
 addition
   to
   the team.
  
   As per the usual, if the current Tempest core team members would
 please vote
   +1
   or -1(veto) to the nomination when you get a chance. We'll keep the
 polls
   open
   for 5 days or until everyone has voted.
  
   References:
  
   https://review.openstack.org/#/q/reviewer:%22Andrea+Frittoli+%22,n,z
  
  
 http://stackalytics.com/?user_id=andrea-frittolimetric=marksmodule=qa-group
  
  
   The second change that I'm proposing today is to remove Giulio Fidente
 from
   the
   core team. He asked to be removed from the core team a few weeks back
 because
   he
   is no longer able to dedicate the required time to Tempest reviews. So
 if
   there
   are no objections to this I will remove him from the core team in a
 few days.
   Sorry to see you leave the team Giulio...
  
  
   Thanks,
  
   Matt Treinish
  
   ___
   OpenStack-dev mailing list
   OpenStack-dev@lists.openstack.org
   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
  
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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


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

[openstack-dev] [TripleO] devtest_seed.sh erroring with a 500

[Ricardo Carrillo Cruz]

Hi guys

Being off some time from using tripleo and now I'm back in business.
I get this error during devtest_seed.sh run:

++ os-apply-config --key baremetal-network.seed.range-end --type raw
--key-default 192.0.2.20
+ BM_NETWORK_SEED_RANGE_END=192.0.2.20
+ setup-neutron 192.0.2.2 192.0.2.20 192.0.2.0/24 192.0.2.1 192.0.2.1
ctlplane
++ keystone tenant-get admin
++ awk '$2==id {print $4}'
+ nova quota-update --cores -1 --instances -1 --ram -1
4bd569caaf704cbcaa3610a49a362a50
+ '[' -z '' ']'
+ setup-baremetal --service-host seed --nodes /dev/fd/63
++ jq '[.nodes[0]]' /home/ricky/tripleo/testenv.json
ERROR: The server has either erred or is incapable of performing the
requested operation. (HTTP 500) (Request-ID:
req-81c5edab-c943-49fd-bc9f-96a96122be26)

Any pointers on how to troubleshoot this further?

Thanks and kind regards
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] devtest_seed.sh erroring with a 500

[Ricardo Carrillo Cruz]

Please disregard, I sent this email to the openstack-dev, instead of the
openstack users mailing list.

Sorry for the noise.


2014-05-24 13:08 GMT+02:00 Ricardo Carrillo Cruz 
ricardo.carrillo.c...@gmail.com:

 Hi guys

 Being off some time from using tripleo and now I'm back in business.
 I get this error during devtest_seed.sh run:

 ++ os-apply-config --key baremetal-network.seed.range-end --type raw
 --key-default 192.0.2.20
 + BM_NETWORK_SEED_RANGE_END=192.0.2.20
 + setup-neutron 192.0.2.2 192.0.2.20 192.0.2.0/24 192.0.2.1 192.0.2.1
 ctlplane
 ++ keystone tenant-get admin
 ++ awk '$2==id {print $4}'
 + nova quota-update --cores -1 --instances -1 --ram -1
 4bd569caaf704cbcaa3610a49a362a50
 + '[' -z '' ']'
 + setup-baremetal --service-host seed --nodes /dev/fd/63
 ++ jq '[.nodes[0]]' /home/ricky/tripleo/testenv.json
 ERROR: The server has either erred or is incapable of performing the
 requested operation. (HTTP 500) (Request-ID:
 req-81c5edab-c943-49fd-bc9f-96a96122be26)

 Any pointers on how to troubleshoot this further?

 Thanks and kind regards

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

Re: [openstack-dev] Gerrit downtime and upgrade on 2014-04-28

[Ricardo Carrillo Cruz]

It would be nice to have a switch on git-review to push patchsets on WIP,
the same way you can do with Draft.

Anyone knows if there is an enhancement request/bug opened against Gerrit
so we could implement it?

Regards


2014-04-25 10:49 GMT+02:00 Roman Podoliaka rpodoly...@mirantis.com:

 Hi all,

  Wouldn't it be better to make this label more persistent?

 +1. It's really annoying to press Work in Progress button every time
 you upload a new patch set.

 Thanks,
 Roman

 On Fri, Apr 25, 2014 at 11:02 AM, Yuriy Taraday yorik@gmail.com
 wrote:
  Hello.
 
  On Wed, Apr 23, 2014 at 2:40 AM, James E. Blair jebl...@openstack.org
  wrote:
 
  * The new Workflow label will have a -1 Work In Progress value which
will replace the Work In Progress button and review state.  Core
reviewers and change owners will have permission to set that value
(which will be removed when a new patchset is uploaded).
 
 
  Wouldn't it be better to make this label more persistent?
  As I remember there were some ML threads about keeping WIP mark across
 patch
  sets. There were even talks about changing git-review to support this.
  How about we make it better with the new version of Gerrit?
 
  --
 
  Kind regards, Yuriy.
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

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

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

[openstack-dev] [TripleO] Documenting supported platforms

[Ricardo Carrillo Cruz]

Hi guys

I opened a bug to state in the documentation that Ubuntu 12.04 is
unsupported and sent a change for it:

https://bugs.launchpad.net/tripleo/+bug/1296576
https://review.openstack.org/#/c/84801/

However, per the initial feedback it seems some developers are interested
in widening the scope of the change a bit and put all platforms that are
currently supported.
My plan is to add a table to the README.md and write up a supported
platforms matrix.
As I'm an Ubuntu user I'm only aware of Ubuntu 12.04 not working and Ubuntu
13.10 working just fine.
I'd like to get your feedback for platforms you use that you know that work
just fine for devtest and those that you know that do not, be Fedora,
OpenSuse or whatever.


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