Can't find gdeploy RPM under CentOS storage sig repo
by Daniel Belenky
Hi Sahina,
My name is Daniel, im from the oVirt infra team.
We are currently trying to find an official CentOS repo wich contains *gdeploy
*RPMs. Usually we can find all the Gluster related RPMs under the Storage
SIG repo, but couldn't find gdeploy there. Is it being released to the
CentOS repos?
Thanks,
--
*Daniel Belenky*
*RHV DevOps*
*Red Hat Israel*
7 years, 4 months
Re: [ovirt-users] [ovirt-devel] Lowering the bar for wiki contribution?
by Roy Golan
Adding infra which I forgot to add from the beginning
On 7 January 2017 at 02:44, Jakub Niedermertl <jniederm(a)redhat.com> wrote:
> On Wed, Jan 4, 2017 at 11:41 AM, Roy Golan <rgolan(a)redhat.com> wrote:
> >
> >
> > On 4 January 2017 at 12:17, Maor Lipchuk <mlipchuk(a)redhat.com> wrote:
> >>
> >>
> >>
> >> On Wed, Jan 4, 2017 at 11:38 AM, Daniel Erez <derez(a)redhat.com> wrote:
> >>>
> >>>
> >>>
> >>> On Wed, Jan 4, 2017 at 9:57 AM, Roy Golan <rgolan(a)redhat.com> wrote:
> >>>>
> >>>> I'm getting the feeling I'm not alone in this, authoring and
> publishing
> >>>> a wiki page isn't as used to be for long time.
> >>>>
> >>>> I want to suggest a bit lighter workflow:
> >>>>
> >>>> 1. Everyone can merge their page - (it's a wiki)
> >>>> Same as with (public and open) code, no one has the motivation to
> >>>> publish a badly written
> >>>> wiki page under their name. True, it can have an impact, but not as
> >>>> with broken code
> >>>>
> >>>
> >>> +1.
> >>> Moreover, I think we shouldn't block any merging. Instead, wiki
> >>> maintainers could act afterwards and revert when needed (Wikipedia
> style).
> >>> Another issue is that (sadly) unlike mediawiki, we need to wait for
> wiki
> >>> publish after a change. So I'd suggest to build and publish the wiki at
> >>> least once a day. Any way, I think we should make the workflow much
> more
> >>> intuitive and pleasant like the previous wiki - i.e. much less
> restrictive
> >>> than manipulating a code base.
> >>>
> >>>
> >>>>
> >>>> 2. Use Page-Status marker
> >>>> The author first merges the draft. Its now out there and should be
> >>>> updated as time goes and its
> >>>> status is DRAFT. Maintainers will come later and after review would
> >>>> change the status to
> >>>> PUBLISH. That could be a header in on the page:
> >>>> ---
> >>>> page status: DRAFT/PUBLISH
> >>>> ---
> >>>>
> >>>> Simple I think, and should work.
> >>>>
> >>
> >> +1
> >> The effort of maintaining the wiki today compare to how it used to be
> >> before is much more cumbersome and problematic.
> >> I think we can learn a lot from wikipedia workflow,
> >> It is a much more inviting process where anyone can change the content
> >> easily.
> >> I'm not saying we should let any anonymous user change the wiki but even
> >> if we make it easier in house we can achieve much more informative
> reliable
> >> and updated wiki.
> >>
> >
> >
> >
> > I really think Github Pages is a perfect fit and an alternative to my
> first
> > suggestion. see
> > https://github.com/oVirt/ovirt-site/wiki/Why-aren't-we-using-this%3F
>
> +1
> Github wiki would allow us instant publishing, review after after
> publishing, it works purely in browser (no need for running local ruby
> server) and it's a service that doesn't require any maintenance form
> our side.
>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Devel mailing list
> >>>> Devel(a)ovirt.org
> >>>> http://lists.ovirt.org/mailman/listinfo/devel
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Users mailing list
> >>> Users(a)ovirt.org
> >>> http://lists.ovirt.org/mailman/listinfo/users
> >>>
> >>
> >
> >
> > _______________________________________________
> > Users mailing list
> > Users(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/users
> >
>
7 years, 5 months
Re: [ovirt-devel] [ OST Failure Report ] [ oVirt master ] [ 27-04-2017 ] [add_hosts]
by Piotr Kliczewski
Nadav,
Yes, vdsm is not able to resolve 'engine' which is used in engine's
certificate.
Thanks,
Piotr
29 kwi 2017 00:37 "Nadav Goldin" <ngoldin(a)redhat.com> napisał(a):
Hi Piotr,
Can you clarify what you noticed is not resolvable - the 'engine' FQDN
from host0?
Thanks,
Nadav.
On Fri, Apr 28, 2017 at 4:15 PM, Piotr Kliczewski <pkliczew(a)redhat.com>
wrote:
> I started to investigate the issue [1] and it seems like there is an issue
> in Lago setup we use.
>
> During handshake we have a step to verify whether client certificate was
> issued for a specific host (no such functionality in m2crytpo code base).
> It works fine when using either ip addresses or fqdns but in this
particular
> setup we use mixed.
>
> When added logging I see that in engine certificate we use 'engine' name
> which is not resolvable on the host side and the check fails.
> I posted a patch [2] which fixes IPv4 mapped addresses issue but we need
to
> fix the setup issue.
>
> Thanks,
> Piotr
>
> [1] http://jenkins.ovirt.org/job/ovirt-system-tests_manual/326/
> [2] https://gerrit.ovirt.org/#/c/76197/
>
> On Thu, Apr 27, 2017 at 3:39 PM, Piotr Kliczewski <pkliczew(a)redhat.com>
> wrote:
>>
>>
>>
>> On Thu, Apr 27, 2017 at 3:13 PM, Evgheni Dereveanchin
>> <ederevea(a)redhat.com> wrote:
>>>
>>> Test failed: 002_bootstrap/add_hosts
>>>
>>> Link to suspected patches:
>>> https://gerrit.ovirt.org/76107 - ssl: change default library
>>>
>>> Link to job:
>>> http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/6491/
>>>
>>> VDSM log:
>>>
>>> http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_
master/6491/artifact/exported-artifacts/basic-suit-master-
el7/test_logs/basic-suite-master/post-002_bootstrap.py/
lago-basic-suite-master-host0/_var_log/vdsm/vdsm.log
>>>
>>> Error snippet from VDSM log, this repeats on each connection attempt
from
>>> Engine side:
>>>
>>> <error>
>>>
>>> 2017-04-27 06:39:27,768-0400 INFO (Reactor thread)
>>> [ProtocolDetector.AcceptorImpl] Accepted connection from
>>> ::ffff:192.168.201.3:49530 (protocoldetector:74)
>>> 2017-04-27 06:39:27,898-0400 ERROR (Reactor thread) [vds.dispatcher]
>>> uncaptured python exception, closing channel
>>> <yajsonrpc.betterAsyncore.Dispatcher connected ('::ffff:192.168.201.3',
>>> 49530, 0, 0) at 0x1cc3b00> (<class 'socket.error'>:Address family not
>>> supported by protocol [/usr/lib64/python2.7/asyncore.py|readwrite|110]
>>> [/usr/lib64/python2.7/asyncore.py|handle_write_event|468]
>>> [/usr/lib/python2.7/site-packages/yajsonrpc/betterAsyncore.py|handle_
write|70]
>>> [/usr/lib/python2.7/site-packages/yajsonrpc/betterAsyncore.py|_delegate_
call|149]
>>> [/usr/lib/python2.7/site-packages/vdsm/sslutils.py|handle_write|213]
>>> [/usr/lib/python2.7/site-packages/vdsm/sslutils.py|_handle_io|223]
>>> [/usr/lib/python2.7/site-packages/vdsm/sslutils.py|_verify_host|237]
>>> [/usr/lib/python2.7/site-packages/vdsm/sslutils.py|compare_names|249])
>>> (betterAsyncore:160)
>>>
>>> </error>
>>
>>
>> This means that what we have in the certificate do not match the source
>> address we get. I suspect that we issue the certificate for 192.168.201.3
>> but when we get ::ffff:192.168.201.3.
>> The change was verified in the env when ipv4 is used. I pushed a revert
>> [1] for now so we can work on fixing the issue.
>>
>> [1] https://gerrit.ovirt.org/#/c/76160
>>
>>>
>>> --
>>> Regards,
>>> Evgheni Dereveanchin
>>
>>
>
>
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
7 years, 6 months
ansible-suite-master failure
by Nadav Goldin
Hi Ondra,
By coincidence when working on a different patch [1] I noticed the
ansible suite is failing on the infra side, this should be fixed in
[2], but now it is failing[3] on something else:
16:46:27 TASK [ovirt-deploy : Remove default datacenter]
********************************
16:46:29 An exception occurred during task execution. To see the full
traceback, use -vvv. The error was: TypeError: expected string or
buffer
16:46:29 fatal: [lago-ansible-suite-master-engine]: FAILED! =>
{"changed": false, "failed": true, "msg": "expected string or buffer"}
16:46:29 to retry, use: --limit
@/home/jenkins/workspace/ovirt-system-tests_master_check-patch-el7-x86_64/ovirt-system-tests/ansible-suite-master/engine.retry
16:46:29
16:46:29 PLAY RECAP
*********************************************************************
16:46:29 lago-ansible-suite-master-engine : ok=14 changed=1
unreachable=0 failed=1
As the none-ansible suite is not failing, I assume this is something
on the ansible side, could you please take a look?
Thanks,
Nadav.
[1] https://gerrit.ovirt.org/#/c/76225
[2] https://gerrit.ovirt.org/#/c/76250
[3] http://jenkins.ovirt.org/job/ovirt-system-tests_master_check-patch-el7-x8...
7 years, 6 months
[JIRA] (OVIRT-1339) Re: Jenkins check-merged failures
by eyal edri [Administrator] (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-1339?page=com.atlassian.jir... ]
eyal edri [Administrator] updated OVIRT-1339:
---------------------------------------------
Resolution: Cannot Reproduce
Status: Done (was: To Do)
> Re: Jenkins check-merged failures
> ---------------------------------
>
> Key: OVIRT-1339
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1339
> Project: oVirt - virtualization made easy
> Issue Type: By-EMAIL
> Reporter: Nadav Goldin
> Assignee: infra
>
> Hi Milan,
> (Adding infra-support to open a ticket)
> For the first job, the automation/deploy.sh script failed, which means
> vdsm failed to install inside the VM created by Lago. I couldn't
> figure out why as the 'deploy.sh' script was missing the bash '-x'
> flag. The /var/log/messages doesn't show any VDSM logs, so I assume it
> failed before. Anyways, now that[1] is merged - it should be easier to
> debug this next time.
> For the second job - this is due to Lago internal reposerver still
> being up from a previous run on the slave. It seems that this[2] vdsm
> check-merged job on April 05 caused it, when it timed-out without
> terminating properly. This is quite rare I should say, we can keep
> this ticket to check if it happens again.
> Either way - I think both failures are unrelated, best would be(if
> still relevant - as check-merged probably ran a few times since) to
> re-trigger and see if it replicates.
> [1] https://gerrit.ovirt.org/#/c/75348/2
> [2] http://jenkins.ovirt.org/job/vdsm_master_check-merged-el7-x86_64/1492/con...
> On Fri, Apr 7, 2017 at 10:32 AM, Milan Zamazal <mzamazal(a)redhat.com> wrote:
> > Hi,
> >
> > a series of 4 my Vdsm patches was merged yesterday and Jenkins has
> > failed on two of them in check-merged. See
> > http://jenkins.ovirt.org/job/vdsm_master_check-merged-el7-x86_64/1504/
> > and
> > http://jenkins.ovirt.org/job/vdsm_master_check-merged-el7-x86_64/1506/.
> >
> > The corresponding errors were:
> >
> > 16:20:09 + lago ovirt deploy
> > 16:20:09 current session does not belong to lago group.
> > 16:20:09 @ Deploy oVirt environment:
> > 16:20:09 # ovirt-role metadata entry will be soon deprecated, instead you should use the vm-provider entry in the domain definition and set it no one of: ovirt-node, ovirt-engine, ovirt-host
> > 16:20:09 # Deploy environment:
> > 16:20:09 * [Thread-2] Deploy VM vdsm_functional_tests_host-el7:
> > 16:20:23 - STDERR
> > 16:20:23
> > 16:20:23
> > 16:20:23 Exiting on user cancel
> > 16:20:23
> > 16:20:23 * [Thread-2] Deploy VM vdsm_functional_tests_host-el7: ERROR (in 0:00:13)
> > 16:20:23 Error while running thread
> > 16:20:23 Traceback (most recent call last):
> > 16:20:23 File "/usr/lib/python2.7/site-packages/lago/utils.py", line 57, in _ret_via_queue
> > 16:20:23 queue.put({'return': func()})
> > 16:20:23 File "/usr/lib/python2.7/site-packages/lago/prefix.py", line 1339, in _deploy_host
> > 16:20:23 host.name(),
> > 16:20:23 RuntimeError: /home/jenkins/workspace/vdsm_master_check-merged-el7-x86_64/vdsm/automation/vdsm_functional/default/scripts/_home_jenkins_workspace_vdsm_master_check-merged-el7-x86_64_vdsm_automation_deploy.sh failed with status 1 on vdsm_functional_tests_host-el7
> > 16:20:23 # Deploy environment: ERROR (in 0:00:13)
> > 16:20:23 @ Deploy oVirt environment: ERROR (in 0:00:14)
> > 16:20:23 Error occured, aborting
> >
> > and
> >
> > 16:21:32 + lago ovirt deploy
> > 16:21:33 current session does not belong to lago group.
> > 16:21:33 @ Deploy oVirt environment:
> > 16:21:33 # ovirt-role metadata entry will be soon deprecated, instead you should use the vm-provider entry in the domain definition and set it no one of: ovirt-node, ovirt-engine, ovirt-host
> > 16:21:33 @ Deploy oVirt environment: ERROR (in 0:00:00)
> > 16:21:33 Error occured, aborting
> > 16:21:33 Traceback (most recent call last):
> > 16:21:33 File "/usr/lib/python2.7/site-packages/ovirtlago/cmd.py", line 303, in do_run
> > 16:21:33 self.cli_plugins[args.ovirtverb].do_run(args)
> > 16:21:33 File "/usr/lib/python2.7/site-packages/lago/plugins/cli.py", line 184, in do_run
> > 16:21:33 self._do_run(**vars(args))
> > 16:21:33 File "/usr/lib/python2.7/site-packages/lago/utils.py", line 495, in wrapper
> > 16:21:33 return func(*args, **kwargs)
> > 16:21:33 File "/usr/lib/python2.7/site-packages/lago/utils.py", line 506, in wrapper
> > 16:21:33 return func(*args, prefix=prefix, **kwargs)
> > 16:21:33 File "/usr/lib/python2.7/site-packages/ovirtlago/cmd.py", line 164, in do_deploy
> > 16:21:33 prefix.deploy()
> > 16:21:33 File "/usr/lib/python2.7/site-packages/lago/log_utils.py", line 633, in wrapper
> > 16:21:33 return func(*args, **kwargs)
> > 16:21:33 File "/usr/lib/python2.7/site-packages/ovirtlago/reposetup.py", line 110, in wrapper
> > 16:21:33 with utils.repo_server_context(args[0]):
> > 16:21:33 File "/usr/lib64/python2.7/contextlib.py", line 17, in __enter__
> > 16:21:33 return self.gen.next()
> > 16:21:33 File "/usr/lib/python2.7/site-packages/ovirtlago/utils.py", line 97, in repo_server_context
> > 16:21:33 root_dir=prefix.paths.internal_repo(),
> > 16:21:33 File "/usr/lib/python2.7/site-packages/ovirtlago/utils.py", line 73, in _create_http_server
> > 16:21:33 generate_request_handler(root_dir),
> > 16:21:33 File "/usr/lib64/python2.7/SocketServer.py", line 419, in __init__
> > 16:21:33 self.server_bind()
> > 16:21:33 File "/usr/lib64/python2.7/BaseHTTPServer.py", line 108, in server_bind
> > 16:21:33 SocketServer.TCPServer.server_bind(self)
> > 16:21:33 File "/usr/lib64/python2.7/SocketServer.py", line 430, in server_bind
> > 16:21:33 self.socket.bind(self.server_address)
> > 16:21:33 File "/usr/lib64/python2.7/socket.py", line 224, in meth
> > 16:21:33 return getattr(self._sock,name)(*args)
> > 16:21:33 error: [Errno 98] Address already in use
> >
> > Do you know what's wrong?
> >
> > Thanks,
> > Milan
> > _______________________________________________
> > Infra mailing list
> > Infra(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/infra
--
This message was sent by Atlassian JIRA
(v1000.929.1#100040)
7 years, 6 months
[JIRA] (OVIRT-1338) Re: Problem in with ovirt-engine-metrics repo
by eyal edri [Administrator] (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-1338?page=com.atlassian.jir... ]
eyal edri [Administrator] updated OVIRT-1338:
---------------------------------------------
Resolution: Fixed
Status: Done (was: To Do)
> Re: Problem in with ovirt-engine-metrics repo
> ---------------------------------------------
>
> Key: OVIRT-1338
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1338
> Project: oVirt - virtualization made easy
> Issue Type: By-EMAIL
> Reporter: Gil Shinar
> Assignee: infra
> Attachments: image.png
>
>
> Hi Shirly,
> Which of the commits below you have pushed?
> [image: Inline image 1]
> Looks like you've pushed patches without rebasing them on master first.
> *Update*, I have sat with Shirly and we have fixed repo credentials to not
> allow merging with rebase first.
> Gil
> On Mon, Apr 24, 2017 at 9:37 PM, Shirly Radco <sradco(a)redhat.com> wrote:
> > Hi,
> >
> >
> > Earlier today I merged 3 patches to ovirt-engine-metrics.
> > When I check the git log I see 4 parches. Each patch has 2 merges.
> > One is the correct one and the other is empty.
> >
> > I don't see this in Gerrit.
> > I tried to clone the repo again but result is the same.
> >
> >
> > See git log :
> >
> > commit 54a16aa73545c3a39401c969cc27c1887a6b1038
> > Merge: 6e97bcd adb51fb
> > Author: Shirly Radco <sradco(a)redhat.com>
> > Date: Mon Apr 24 06:20:06 2017 -0400
> >
> > Merge "collectd: updated engine processes plugin"
> >
> > commit 6e97bcd7969ab3dbbb60796f5035343ee14f40d7
> > Merge: 0b63697 3466a8b
> > Author: Shirly Radco <sradco(a)redhat.com>
> > Date: Mon Apr 24 06:19:57 2017 -0400
> >
> > Merge "collectd: Fixed processes plugin configurations"
> >
> > commit 0b636971dc7b415b0831edc4abac2493347a5cfe
> > Author: Shirly Radco <sradco(a)redhat.com>
> > Date: Sun Apr 9 11:43:14 2017 +0300
> >
> > fluentd: added prefix to the statsd value field
> >
> > Since statds records can be host or vm metrics,
> > I added vm/host prefix to the metric value
> > field name, so the user can choose the required
> > :...skipping...
> > commit 54a16aa73545c3a39401c969cc27c1887a6b1038
> > Merge: 6e97bcd adb51fb
> > Author: Shirly Radco <sradco(a)redhat.com>
> > Date: Mon Apr 24 06:20:06 2017 -0400
> >
> > Merge "collectd: updated engine processes plugin"
> >
> > commit 6e97bcd7969ab3dbbb60796f5035343ee14f40d7
> > Merge: 0b63697 3466a8b
> > Author: Shirly Radco <sradco(a)redhat.com>
> > Date: Mon Apr 24 06:19:57 2017 -0400
> >
> > Merge "collectd: Fixed processes plugin configurations"
> >
> > commit 0b636971dc7b415b0831edc4abac2493347a5cfe
> > Author: Shirly Radco <sradco(a)redhat.com>
> > Date: Sun Apr 9 11:43:14 2017 +0300
> >
> > fluentd: added prefix to the statsd value field
> >
> > Since statds records can be host or vm metrics,
> > I added vm/host prefix to the metric value
> > field name, so the user can choose the required
> > metric easily.
> >
> > Change-Id: Ib71dbba78f3922fe1d257c83480867f485a91c22
> > Signed-off-by: Shirly Radco <sradco(a)redhat.com>
> >
> >
> > Please see why.
> > I want to build for 4.1.2 and need to be sure repo is ok.
> >
> > Thank you,
> >
> > --
> >
> > SHIRLY RADCO
> >
> > BI SOFTWARE ENGINEER,
> >
> > Red Hat Israel <https://www.redhat.com/>
> >
> > sradco(a)redhat.com
> > <https://red.ht/sig>
> > <https://redhat.com/summit>
> >
> >
> > _______________________________________________
> > Infra mailing list
> > Infra(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/infra
> >
> >
--
This message was sent by Atlassian JIRA
(v1000.929.1#100040)
7 years, 6 months
