Re: [openstack-dev] [nova][vmware] need help triaging a vmware driver bug
On 23.08.2018 23:27, melanie witt wrote: So, I think we could add something to the launchpad bug template to link to a doc that explains tips about reporting VMware related bugs. I suggest linking to a doc because the bug template is already really long and looks like it would be best to have something short, like, "For tips on reporting VMware virt driver bugs, see this doc: " and provide a link to, for example, a openstack wiki about the VMware virt driver (is there one?). The question is, where can we put the doc? Wiki? Or maybe here at the bottom [1]? Let me know what you think. Sorry for the late reply, I was on PTO last week. I have posted a patch which adds a "Troubleshooting" section to the VMware documentation in Nova: https://review.openstack.org/#/c/597446 If this is OK then we can add a link to this particular paragraph in the bug template. Thanks, Rado __ 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] [nova][vmware] need help triaging a vmware driver bug
Hi, On 17.08.2018 04:10, melanie witt wrote: Can anyone help triage this bug? I have requested more info from the person who submitted this and provided some tips how to correlate nova-compute logs to vCenter logs in order to better understand what went wrong. Would it be possible to include this kind of information in the Launchpad bug template for VMware related bugs? Thanks, Rado __ 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] [nova] VMware NSX CI - no longer running?
On 28.03.2018 19:07, melanie witt wrote: We were reviewing a bug fix for the vmware driver [0] today and we noticed it appears that the VMware NSX CI is no longer running, not even on only the nova/virt/vmwareapi/ tree. From the third-party CI dashboard, I see some claims of it running but when I open the patches, I don't see any reporting from VMware NSX CI [1]. Can anyone from the vmware subteam comment on whether or not the vmware third-party CI is going to be fixed or if it has been abandoned? While running the VMware CI continues to be a challenge, I must say this patch fixes a regression introduced by Matt Riedemann's patch: https://review.openstack.org/#/c/549411/ for which the VMware CI clearly indicated there was a problem and nevertheless the core team submitted it. Before blaming the CI for not voting enough, the core team should start taking into account existing CI votes. It'd be nice also to include VMware driver maintainers as reviewers when making changes to the VMware driver. __ 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] [nova] VM console for VMware instances
On 25.08.2016 18:25, Andrew Laski wrote: > Is there a reason this has not been proposed to the Nova project, or > have I missed that? I looked for a proposal and did not see one. > The main reason I developed this out of tree is that reviewing patches in Nova takes forever. For example this patch[1] that propose changes in this part of the code base has been in review for 2 years. > I see that there's support in Nova and python-novaclient for this > feature, but the actual proxy is not in the Nova tree. In situations > like this, where there's in-tree code to support an out of tree feature, > we typically deprecate and remove that code unless there's a plan to > move all of the components into the project. I don't think this is the case for console proxies. The RDP console proxy is also developed out of tree, in C++[2]. We can't expect that all vendors will commit their proxy implementations in the Nova tree for various technical reasons. In the VMware case, there are no technical reasons which prevent putting mksproxy in the Nova tree, I decided to start its development out of tree only because reviewing patches in Nova takes forever. > Is there a plan to move this proxy into Nova? > I will propose adding mksproxy in the Nova tree for the next release and if it is accepted, I will deprecate nova-mksproxy. [1] https://review.openstack.org/#/c/115483/ [2] https://cloudbase.it/freerdp-html5-proxy-windows/ __ 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] [nova] VM console for VMware instances
Hi, If you want to use the MKS console for VMware instances, it's now possible with the nova-mksproxy[1]. There is a devstack plugin, so simply add this in your local.conf: [[local|localrc]] enable_plugin nova-mksproxy https://github.com/openstack/nova-mksproxy the CLI command for getting a console URL is: $ nova get-mks-console This is the preferred console type for VMware instances because it doesn't require any configuration changes on the hypervisor (whereas VNC requires opening network ports). Any comments/feedback is welcome. -Rado [1] https://github.com/openstack/nova-mksproxy __ 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] [nova] Live migration with the VMware driver
Hi, I posted a patch which implements live migration with the VMware driver: https://review.openstack.org/#/c/270116 The assumption is that each nova-compute is managing a cluster in the same vCenter server. In that case the only information that we need from the destination node is the cluster name and the datastore regex. Any feedback is appreciated. Thanks, Rado __ 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] [nova] API for getting connection info from console token
FYI, I have filed a bug to track this: https://bugs.launchpad.net/nova/+bug/1485529 It'd be really nice to fix this in the L release. Thanks, Rado On 4.08.2015 14:18, Radoslav Gerganov wrote: There is an API (os-console-auth-tokens) which returns the connection info which correspond to a given console token. However this API works only for RDP consoles: https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_nova_blob_master_nova_api_openstack_compute_plugins_v3_console-5Fauth-5Ftokens.py-23L49d=BQICAgc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=h6VMsoP9gXKqcB9YSgf6Ulb3sLQs54a0wyrIaBfgTycm=FATeZ0i_z3wTCwBbjWhupJ0uwMfYUxD1pebEQ39ASCEs=gqOn9k4HiCz1jD3LZxlMZrAQFcL57Euqh3cZkaZ5XHke= Why do we have this restriction? We need the same API for MKS consoles as well. I have posted the following patch: https://review.openstack.org/#/c/208998/ but I'd prefer to remove the type check altogether and make it work for all types of consoles. I don't see any reason to restrict the API only for certain types of VM consoles. What do you think? Thanks, Rado __ 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] [nova] API for getting connection info from console token
There is an API (os-console-auth-tokens) which returns the connection info which correspond to a given console token. However this API works only for RDP consoles: https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/plugins/v3/console_auth_tokens.py#L49 Why do we have this restriction? We need the same API for MKS consoles as well. I have posted the following patch: https://review.openstack.org/#/c/208998/ but I'd prefer to remove the type check altogether and make it work for all types of consoles. I don't see any reason to restrict the API only for certain types of VM consoles. What do you think? Thanks, Rado __ 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] [oslo][oslo-vmware] Core review team
+1, it'd be great to have Eric in the oslo.vmware team -Rado On 7/2/15 8:03 PM, Gary Kotton wrote: Hi, Over time the team of people working in the project has changed and evolved. We would like to add the following people following their contributions for the project: * Eric Brown We would like to remove the following people as they are no longer working on the project and thank them for their contributions: * Vui Lam * Arnaud Legendre * Kartik Bommepally * Subbu * Shawn Hartsock Thanks Gary __ 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] [Nova] The unbearable lightness of specs
On 06/24/2015 03:42 PM, Daniel P. Berrange wrote: On Wed, Jun 24, 2015 at 11:28:59AM +0100, Nikola Đipanov wrote: Hey Nova, I'll cut to the chase and keep this email short for brevity and clarity: Specs don't work! They do nothing to facilitate good design happening, if anything they prevent it. The process layered on top with only a minority (!) of cores being able to approve them, yet they are a prereq of getting any work done, makes sure that the absolute minimum that people can get away with will be proposed. This in turn goes and guarantees that no good design collaboration will happen. To add insult to injury, Gerrit and our spec template are a horrible tool for discussing design. Also the spec format itself works for only a small subset of design problems Nova development is faced with. I'd like to see some actual evidence to backup a sweeping statement as Specs dont work. They do nothing to facilitate good design happening, if anything they prevent it. Here is actual evidence: my spec[1] for changing the console API has been approved twice (in Kilo and Liberty), then it was augmented by the API WG [2], the implementation has been in review for 6 months [3] and there is still no agreement on this API change. I am not talking about implementation details but fundamental things that should be cleared out during the spec review. So writing and reviewing this spec was pretty much a waste of time. [1] http://specs.openstack.org/openstack/nova-specs/specs/liberty/approved/consolidate-console-api.html [2] https://github.com/openstack/nova-specs/commit/12f85fcdc1797370f1a962cc9dc14cc634e22b1a [3] https://review.openstack.org/#/c/148509/ -Rado __ 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] [nova] import OVA/OVF into openstack
Hi, On 06/24/2015 11:19 PM, Xingjun Chu wrote: Hi, Not sure if I should send this to glance or nova project, anyways ... As far as I know, Openstack today does not support OVA/OVF image natively (correct me if I were wrong). I am wondering if there is any plan to support them? Also Any recommendations for now to migrate OVA/OVF into openstack is greatly appreciated... OVA is supported if you use the VMware driver in Nova. The image needs to be imported in Glance like this: glance image-create --property vmware_disktype=streamOptimized --property vmware_adaptertype=ide --name foo --container-format ova --disk-format vmdk The support for this has been added in Kilo with this commit: https://github.com/openstack/nova/commit/53abbc3b479195812e962b6fb7785022af3aeca0 Let me know if you need more info on this. -Rado __ 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] [nova] Request spec freeze exception for “Native HTML5 consoles for VMware”
I’d like to request an exception for: https://review.openstack.org/#/c/127283/ The dependent spec for consolidation of the console APIs is already approved, so now we have a clean way to add a new API for VMware. Thanks, Rado __ 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] [all][gerrit] Showing all inline comments from all patch sets
I never liked how Gerrit is displaying inline comments and I find it hard to follow discussions on changes with many patch sets and inline comments. So I tried to hack together an html view which display all comments grouped by patch set, file and commented line. You can see the result at http://gerrit-mirror.appspot.com/change-id. Some examples: http://gerrit-mirror.appspot.com/127283 http://gerrit-mirror.appspot.com/128508 http://gerrit-mirror.appspot.com/83207 There is room for many improvements (my css skills are very limited) but I am just curious if someone else finds the idea useful. The frontend is using the same APIs as the Gerrit UI and the backend running on GoogleAppEngine is just proxying the requests to review.openstack.org. So in theory if we serve the html page from our Gerrit it will work. You can find all sources here: https://github.com/rgerganov/gerrit-hacks. Let me know what you think. Thanks, Rado ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][gerrit] Showing all inline comments from all patch sets
On 12/16/2014 03:59 PM, Jeremy Stanley wrote: I'm having trouble locating the source code for Google App Engine, and can instead only find source code for its SDK. How would we run a GAE instance? (Please remember that our Infra team doesn't host content backed by proprietary services, but do encourage Google to release this under a free license if they haven't already.) Hi Jeremy, We don't need GoogleAppEngine if we decide that this is useful. We simply need to put the html page which renders the view on https://review.openstack.org. It is all javascript which talks asynchronously to the Gerrit backend. I am using GAE to simply illustrate the idea without having to spin up an entire Gerrit server. I guess I can also submit a patch to the infra project and see how this works on https://review-dev.openstack.org if you want. Thanks, Rado ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][gerrit] Showing all inline comments from all patch sets
I am aware of this New Screen but it is not useful to me. I'd like to see comments grouped by patchset, file and commented line rather than a flat view mixed with everything else. Anyway, I guess there is no one-size-fits-all solution for this and everyone has different preferences which is cool. -Rado On 12/17/14, 8:58 AM, James Polley wrote: I was looking at the new change screen on https://review.openstack.org today[1] and it seems to do something vaguely similar. Rather than saying James polley made 4 inline comments, the contents of the comments are shown, along with a link to the file so you can see the context. Have you seen this? It seems fairly similar to what you're wanting. Have [1] To activate it, go to https://review.openstack.org/#/settings/preferences and set Change view to New Screen, then look at a change screen (such as https://review.openstack.org/#/c/127283/) On Tue, Dec 16, 2014 at 4:45 PM, Jeremy Stanley fu...@yuggoth.org mailto:fu...@yuggoth.org wrote: On 2014-12-16 17:19:55 +0200 (+0200), Radoslav Gerganov wrote: We don't need GoogleAppEngine if we decide that this is useful. We simply need to put the html page which renders the view on https://review.openstack.org. It is all javascript which talks asynchronously to the Gerrit backend. I am using GAE to simply illustrate the idea without having to spin up an entire Gerrit server. That makes a lot more sense--thanks for the clarification! I guess I can also submit a patch to the infra project and see how this works onhttps://review-dev.openstack.org if you want. If there's a general desire from the developer community for it, then that's probably the next step. However, ultimately this seems like something better suited as an upstream feature request for Gerrit (there may even already be thread-oriented improvements in the works for the new change screen--I haven't kept up with their progress lately). -- Jeremy Stanley ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto: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] [nova] Kilo specs review day
On 12/15/2014 12:54 PM, Neil Jerram wrote: My Nova spec (https://review.openstack.org/#/c/130732/) does not appear on this dashboard, even though I believe it's in good standing and - I hope - close to approval. Do you know why - does it mean that I've set some metadata field somewhere wrongly? The dashboard doesn't show your own specs. You have to remove +NOT+owner%3Aself from the URL to see them. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][neutron][cinder] Averting the Nova crisis by splitting out virt drivers
On 09/11/2014 04:30 PM, Sean Dague wrote: On 09/11/2014 09:09 AM, Gary Kotton wrote: On 9/11/14, 2:55 PM, Thierry Carrez thie...@openstack.org wrote: Sean Dague wrote: [...] Why don't we start with let's clean up the virt interface and make it more sane, as I don't think there is any disagreement there. If it's going to take a cycle, it's going to take a cycle anyway (it will probably take 2 cycles, realistically, we always underestimate these things, remember when no-db-compute was going to be 1 cycle?). I don't see the need to actually decide here and now that the split is clearly at least 7 - 12 months away. A lot happens in the intervening time. Yes, that sounds like the logical next step. We can't split drivers without first doing that anyway. I still think people need smaller areas of work, as Vish eloquently put it. I still hope that refactoring our test architecture will let us reach the same level of quality with only a fraction of the tests being run at the gate, which should address most of the harm you see in adding additional repositories. But I agree there is little point in discussing splitting virt drivers (or anything else, really) until the internal interface below that potential split is fully cleaned up and it becomes an option. How about we start to try and patch gerrit to provide +2 permissions for people Who can be assigned Œdriver core¹ status. This is something that is relevant to Nova and Neutron and I guess Cinder too. If you think that's the right solution, I'd say go and investigate it with folks that understand enough gerrit internals to be able to figure out how hard it would be. Start a conversation in #openstack-infra to explore it. My expectation is that there is more complexity there than you give it credit for. That being said one of the biggest limitations we've had on gerrit changes is we've effectively only got one community member, Kai, who does any of that. If other people, or teams, were willing to dig in and own things like this, that might be really helpful. I don't think we need to modify gerrit to support this functionality. We can simply have a gerrit job (similar to the existing CI jobs) which is run on every patch set and checks if: 1) the changes are only under /nova/virt/XYZ and /nova/tests/virt/XYZ 2) it has two +1 from maintainers of driver XYZ if the above conditions are met, the job will post W+1 for this patchset. Does that make sense? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][vmware] Convert to rescue by adding the rescue image and booting from it
Definitely +1. This change will allow us to get rid of the of the ugly special cases where we use the instance name instead of the uuid and will make the code cleaner. Let's go for it! Thanks, Rado - Original Message - Currently we create a rescue instance by creating a new VM with the original instance's image, then adding the original instance's first disk to it, and booting. This means we have 2 VMs, which we need to be careful of when cleaning up. Also when suspending, and probably other edge cases. We also don't support: * Rescue images other than the instance's creation image * Rescue of an instance which wasn't created from an image * Access to cinder volumes from a rescue instance I've created a dirty hack which, instead of creating a new VM, attaches the given rescue image to the VM and boots from it: https://review.openstack.org/#/c/106078/ It works for me. It supports all of the above, doesn't require special handling on destroy, and works with suspend[1]. It also doesn't trigger the spurious warning message about unknown VMs on the cluster which, while unimportant in itself, is an example of an edge case caused by having 2 VMs. Does this seem a reasonable way to go? It would be dependent on a refactoring of the image cache code so we could cache the rescue image. Matt [1] If suspend of a rescued image wasn't broken at the api level, anyway. I have a patch for that: https://review.openstack.org/#/c/106082/ -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 ___ 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] [nova] [VMware] Can someone help to look at this bug https://bugs.launchpad.net/nova/+bug/1338881
Hi David, - Original Message - From: Jian Hua Geng gen...@cn.ibm.com To: openstack-dev openstack-dev@lists.openstack.org Sent: Tuesday, July 8, 2014 8:00:01 AM Subject: [openstack-dev] [nova] [VMware] Can someone help to look at this bug https://bugs.launchpad.net/nova/+bug/1338881 Hi All, Can someone help to look at this bug that is regarding the non-admin user connect to vCenter when run nova compute services? I have commented on the bug. I think that you need to add 'Sessions.TerminateSession' privilege to your account. This is required in order to terminate inactive sessions. Thanks, Rado ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Set compute_node:hypervisor_nodename as unique and not null
As we knew, Nova db has the table “compute_nodes” for modelling the hypervisors and its using the “hypervisor_hostname” field to represent the hypervisor name. This value is having significant value in os-hypervisor extension api which is using this field to uniquely identify the hypervisor. Consider the case where a given environment is having more than one hypervisors (KVM, EXS, Xen, etc) with same hostname and os-hypervisor and thereby Horizon Hypervisor panel and nova hypervisors-servers command will fail. There is a defect ( https://bugs.launchpad.net/nova/+bug/1329261 ) already filed on VMware VC driver to address this issue to make sure that, a unique value is generated for the VC driver’s hypervisor. But its good to fix at the model level as well by making “hypervisor_hostname” field as unique always. And a bug https://bugs.launchpad.net/nova/+bug/1329299 is filed for the same. Hi Kanagaraj, Thanks for filing these bugs. For the VMware driver we can use a combination of the vCenter uuid and the id of the cluster which is managed by Nova. I have already posted some comments on your patch for this: https://review.openstack.org/#/c/99623/ I am also +1 for adding an unique constraint for the hypervisor_hostname column. Thanks, Rado ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][Oslo.cfg] Configuration string substitution
Hi,
On Wed, Jun 18, 2014 at 4:47 AM, Gary Kotton gkot...@vmware.com wrote:
Hi,
I have encountered a problem with string substitution with the nova
configuration file. The motivation was to move all of the glance settings
to
their own section (https://review.openstack.org/#/c/100567/). The
glance_api_servers had default setting that uses the current glance_host
and
the glance port. This is a problem when we move to the ‘glance’ section.
First and foremost I think that we need to decide on how we should denote
the string substitutions for group variables and then we can dive into
implementation details. Does anyone have any thoughts on this?
My thinking is that when we use we should use a format of $group.key.
An
example is below.
Do we need to set the variable off somehow to allow substitutions that
need the literal '.' after a variable? How often is that likely to
come up?
I would suggest to introduce a different form of placeholder for this like:
default=['${glance.host}:${glance.port}']
similar to how variable substitutions are handled in Bash. IMO, this is more
readable and easier to parse.
-Rado
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Hide CI comments in Gerrit
Hi Monty, As a next step - why not take the Javascript you've got there and submit it as a patch to the file above? We can probably figure out a way to template the third party CI names ... but starting one step at a time is a great idea. Thanks for the pointer, I have submitted https://review.openstack.org/#/c/95743 It is still a work in progress as I need to figure out how to augment only review pages, not the entire Gerrit interface. What would be a good way to test this kind of changes? I have been told there is Gerrit dev box out there. I guess I can also test it with an http proxy that rewrites the pages from the upstream Gerrit but I am looking for something easier :) Having template for CI names would be very helpful indeed. Thanks, Rado ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all] Hide CI comments in Gerrit
Hi, I created a small userscript that allows you to hide CI comments in Gerrit. That way you can read only comments written by humans and hide everything else. I’ve been struggling for a long time to follow discussions on changes with many patch sets because of the CI noise. So I came up with this userscript: https://gist.github.com/rgerganov/35382752557cb975354a It adds “Toggle CI” button at the bottom of the page that hides/shows CI comments. Right now it is configured for Nova CIs, as I contribute mostly there, but you can easily make it work for other projects as well. It supports both the “old” and “new” screens that we have. How to install on Chrome: open chrome://extensions and dragdrop the script there How to install on Firefox: install Greasemonkey first and then open the script Known issues: - you may need to reload the page to get the new button - I tried to add the button somewhere close to the collapse/expand links but it didn’t work for some reason Hope you will find it useful. Any feedback is welcome :) Thanks, Rado ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
