Re: [ovirt-devel] Empty Dropdown Menus in Webadmin

[Phillip Bailey]

On Tue, May 31, 2016 at 1:14 PM, Alexander Wels <aw...@redhat.com> wrote:

> After rebasing and recompiling did you re-run engine-setup, its highly
> likely
> some tables or something changed and you are seeing errors in the log due
> to
> not having run engine-setup.
>

Alex/Vojtech,

Disregard. The issue seems to have resolved itself, which is odd since I
didn't restart the engine. It was a fresh install, so it was a brand new
database and I had run setup prior to starting the engine. If the issue
occurs again, I'll make sure to take some screenshots.

Thanks for the help and sorry for the false alarm.


>
> On Tuesday, May 31, 2016 10:01:02 AM Vojtech Szocs wrote:
> > Hi Phillip,
> >
> > can you please share some screenshots?
>
>
> > Thanks,
> > Vojtech
> >
> >
> > - Original Message -
> >
> > > From: "Phillip Bailey" <phbai...@redhat.com>
> > > To: devel@ovirt.org
> > > Sent: Tuesday, May 31, 2016 2:47:31 PM
> > > Subject: [ovirt-devel] Empty Dropdown Menus in Webadmin
> > >
> > > Hi,
> > >
> > > Is anyone else experiencing empty dropdown menus in webadmin? I started
> > > having the problem after rebasing Friday afternoon. I rebased again
> this
> > > morning, but am still experiencing the same problem. I'm trying to
> > > determine whether this is something isolated to my environment, or a
> more
> > > widespread issue.
> > >
> > > I appreciate any advice any of you may be able to offer.
> > >
> > > Thanks!
> > >
> > > -Phillip Bailey
> > >
> > > ___
> > > Devel mailing list
> > > Devel@ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/devel
> >
> > ___
> > Devel mailing list
> > Devel@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] Empty Dropdown Menus in Webadmin

[Phillip Bailey]

Hi,

Is anyone else experiencing empty dropdown menus in webadmin? I started
having the problem after rebasing Friday afternoon. I rebased again this
morning, but am still experiencing the same problem. I'm trying to
determine whether this is something isolated to my environment, or a more
widespread issue.

I appreciate any advice any of you may be able to offer.

Thanks!

-Phillip Bailey
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Hello and a question about QEMU log

[Phillip Bailey]

Hi,

The libvirt team would be better equipped to address that question, as that
functionality is actually a part of that project. Their contact information
can be found here: https://libvirt.org/contact.html.

-Phillip Bailey

On Sun, Mar 27, 2016 at 10:04 PM, zhukaijie <kjzh...@is.ac.cn> wrote:

> Hello,
> Each running VM has it's command line logged in
> /var/log/libvirt/qemu/${vmname}. And now I'd like to disable this log
> function, that is to say, not to record the QEMU command line of VM. Could
> you please tell me will can I configure it?
> Best wishes.
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Moving configuration files to separate directory

[Phillip Bailey]

On Tue, Aug 2, 2016 at 4:06 AM, Martin Polednik 
wrote:

> Hey devels,
>
> last week, I've been working on patch series that moves most of
> configuration and "static" files away from our source code to a dir
> called "static"[1]. (based on the previous' week VDSM weekly)
>
> Current version has static dir's layout as flat - keeping all files in
> the directory with few exceptions (mom.d and systemd). The downside of
> the approach is that we still have to rename some of the files in
> makefile due to possibility of name clashes if we had similarly named
> files (50_vdsm from sudoers and 50_vdsm anything else).
>
> There is another possibility - hierarchy within the folder. Instead of
> current structure -
>
> static
> ├── Makefile.am
> ├── limits.conf
> ├── logger.conf.in
> ├── mom.conf.in
> ├── mom.d
> │   ├── 00-defines.policy
> │   ├── 01-parameters.policy
> │   ├── 02-balloon.policy
> │   ├── 03-ksm.policy
> │   ├── 04-cputune.policy
> │   ├── 05-iotune.policy
> │   └── Makefile.am
> ├── sudoers.vdsm.in
> ├── svdsm.logger.conf.in
> ├── systemd
> │   ├── Makefile.am
> │   ├── mom-vdsm.service.in
> │   ├── supervdsmd.service.in
> │   ├── vdsm-network.service.in
> │   └── vdsmd.service.in
> ├── vdsm-bonding-modprobe.conf
> ├── vdsm-logrotate.conf
> ├── vdsm-modules-load.d.conf
> ├── vdsm-sysctl.conf
> └── vdsm.rwtab.in
>
> we could structure the directory to a corresponding subfolders over
> the system:
>
> etc
> ├── modprobe.d
> │   └── vdsm-bonding-modprobe.conf
> ├── modules-load.d
> │   └── vdsm.conf
> ├── rwtab.d
> │   └── vdsm
> ├── security
> │   └── limits.d
> │   └── 99-vdsm.conf
> ├── sudoers.d
> │   ├── 50_vdsm
> ├── sysctl.d
> │   └── vdsm.conf
> └── vdsm
>├── logger.conf
>├── logrotate
>│   └── vdsm
>├── mom.conf
>├── mom.d
>│   ├── 00-defines.policy
>│   ├── 01-parameters.policy
>│   ├── 02-balloon.policy
>│   ├── 03-ksm.policy
>│   ├── 04-cputune.policy
>│   └── 05-iotune.policy
>├── svdsm.logger.conf
>├── vdsm.conf
>└── vdsm.conf.d
>
> There is little downside to the second approach, that is more code is
> added to VDSM in a sense that more makefiles will have to exist. On
> the other hand, we can drop all the renaming and have the files named
> as they would be named on their destination after install.
> Opinions?
>

For my two cents, I prefer the second option. One to one name matching is
definitely preferable to renaming, in my opinion.

> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Best (and up-to-date) practices for developers?

[Phillip Bailey]

+1 for the idea if it doesn't already exist. It would ease development for
those already working on the project, but it would also make it easier for
others who would like to contribute to it, but aren't comfortable with
navigating such a large code base.

-Phillip Bailey

On Mon, Sep 19, 2016 at 3:56 AM, Martin Sivak <msi...@redhat.com> wrote:

> Hi,
>
> I just wanted to find out if we have some documentation for the
> developers that would give hint on different aspects of the engine
> development in terms of coding.
>
> Like:
> - code style (we have the config in sources)
> - what libraries are (not) allowed (guava..ehm..)
> - how should CDI be used (see https://gerrit.ovirt.org/#/c/63747/)
> - what files need to be touched to properly support translations
> - ...
>
>
> It would be cool to have something brief we can search easily. I know
> it can get outdated fast, but if we use it only for the important
> stuff and review it for each major release (as the major rules do not
> change much) we should be able to keep it usable.
>
> --
> Martin Sivák
> SLA / oVirt
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Best (and up-to-date) practices for developers?

[Phillip Bailey]

I like that idea. I would prefer having the smaller, more focused files in
a directory. I would probably call it documentation or something similar,
though.

-Phillip Bailey

On Tue, Sep 20, 2016 at 9:14 AM, Roy Golan <rgo...@redhat.com> wrote:

>
>
> On 19 September 2016 at 15:18, Martin Betak <mbe...@redhat.com> wrote:
>
>> Yeah definitely +1.
>>
>> Even after being with the project for some time, I often wonder about
>> things
>> like in what order should fields in class be based on their function (as
>> in
>> logger, static sonstants, @Injected dependencies, actual instance
>> fields...)
>> so such document could answer questions like this (that are not encoded in
>> existing checkstyle rules) or provide general high-level guidance
>> throughout
>> the code base - at least for things that don't change that much. For
>> example
>> I believe that the process to invoke a command (or a query) from the
>> Backend
>> via the VdcActionType, CommandFactory .etc hasn't changed that much,
>> and probably won't change in the foreseeable future :-)
>>
>> Martin B.
>>
>> - Original Message -
>> > From: "Phillip Bailey" <phbai...@redhat.com>
>> > To: "Martin Sivak" <msi...@redhat.com>
>> > Cc: "engine-de...@ovirt.org" <devel@ovirt.org>
>> > Sent: Monday, September 19, 2016 1:54:23 PM
>> > Subject: Re: [ovirt-devel] Best (and up-to-date) practices for
>> developers?
>> >
>> > +1 for the idea if it doesn't already exist. It would ease development
>> for
>> > those already working on the project, but it would also make it easier
>> for
>> > others who would like to contribute to it, but aren't comfortable with
>> > navigating such a large code base.
>> >
>> > -Phillip Bailey
>> >
>> > On Mon, Sep 19, 2016 at 3:56 AM, Martin Sivak < msi...@redhat.com >
>> wrote:
>> >
>> >
>> > Hi,
>> >
>> > I just wanted to find out if we have some documentation for the
>> > developers that would give hint on different aspects of the engine
>> > development in terms of coding.
>> >
>> > Like:
>> > - code style (we have the config in sources)
>> > - what libraries are (not) allowed (guava..ehm..)
>> > - how should CDI be used (see https://gerrit.ovirt.org/#/c/63747/ )
>> > - what files need to be touched to properly support translations
>> > - ...
>> >
>> >
>> > It would be cool to have something brief we can search easily. I know
>> > it can get outdated fast, but if we use it only for the important
>> > stuff and review it for each major release (as the major rules do not
>> > change much) we should be able to keep it usable.
>> >
>> > --
>> > Martin Sivák
>> > SLA / oVirt
>> > ___
>> > Devel mailing list
>> > Devel@ovirt.org
>> > http://lists.ovirt.org/mailman/listinfo/devel
>> >
>> >
>> > ___
>> > Devel mailing list
>> > Devel@ovirt.org
>> > http://lists.ovirt.org/mailman/listinfo/devel
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>
>
> I'm all for creating a series of files under our repo for that (and not
> under ovirt-site)
> Something like:
>
> ovirt-engine/
>  - ENGINE_OVERVIEW.adoc
>  - INTERNAL_APIS.adoc
>  - BEST_PRACTICES.adoc
>  - CODING_GUIDES.adoc
>  - REVIEW_GUIDES.adoc
>
> - Another option is to create a long DEVELOPER.adoc (harder to maintain)
> - Or put all those under ovirt-engine/developer/
>
> * I remember there was an initiative for code-of-conduct. Is it alive?
>
>
>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] Issues Running Engine Setup Related to Database Autovacuum Settings

[Phillip Bailey]

Hi team,

I'm having trouble running engine-setup on a fresh database. When I first
ran setup I received a message prompting me to update the
autovacuum_vacuum_scale_factor, which I did. I then received another
prompting me to update the autovacuum_analyze_scale_factor, which I also
did. The next prompted me to update the autovacuum_max_workers to a value
of at least 6. I have tried changing the value to both 6 and 7 multiple
times, but it doesn't acknowledge that the change has been made and won't
let me proceed with setup.

Could someone tell me if I'm doing something wrong or if this is an issue
with the new feature?

Thanks!

-Phillip Bailey
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] New design for the Gerrit UI

[Phillip Bailey]

It looks great to me, except for one issue. The contrast between the box
around the active item on the second row and the header background color is
too low to make the active item easily identifiable. The same goes for the
box on the first row, but the underline makes it a non-issue. I recommend
either adding an underline to the second row active item or selecting a
better background color for it.

-Phillip Bailey

On Mon, May 8, 2017 at 2:40 AM, Eldan Hildesheim <i...@eldanet.com> wrote:

> Hi,
> Can we insert a new css package easily? Perhaps I can merge Patternfly
> inside which will be very suitable for this case.
> E.
>
> On May 7, 2017, at 11:41 PM, Roy Golan <rgo...@redhat.com> wrote:
>
>
> The footer links are useful but the footer itself has no presence.  Most
> dashboards will fill a page and with such a thin footer nobody is going to
> look at what is has to offer. So we can make the footer in a different
> color and noticeable etc or move the links to the header.
>
> On Sun, May 7, 2017 at 10:35 AM Barak Korren <bkor...@redhat.com> wrote:
>
>> The current scheme seems a little buggy on FF. See how the top green bar
>> is not stretched to cover the top of the oVirt logo.
>>
>>
>>
>> On 6 May 2017 at 12:49, Yaniv Kaul <yk...@redhat.com> wrote:
>>
>>>
>>>
>>> On Fri, May 5, 2017 at 5:33 PM, Greg Sheremeta <gsher...@redhat.com>
>>> wrote:
>>>
>>>> Here's my take.
>>>>
>>>> The line on the top is a little thicker than I like, but we have the
>>>> same thickness in oVirt (I checked). I'm ok with shrinking it in both
>>>> places.
>>>>
>>>> I put in the logo from the oVirt login page. I added patternfly and
>>>> bootstrap. Changed the font to OpenSans. Positioned things and fixed
>>>> paddings. Changed the button and form field to patternfly type (blue 
>>>> button)
>>>>
>>>
>>> Looks very good now. I wonder how far are we from being ADA compliant
>>> (also a general question to our UI - I know Patternfly should help us there
>>> as well).
>>> Y.
>>>
>>>
>>>
>>>>
>>>> Best wishes,
>>>> Greg
>>>>
>>>>
>>>> On Fri, May 5, 2017 at 2:15 AM, Roy Golan <rgo...@redhat.com> wrote:
>>>>
>>>>>
>>>>> Adding UX people +Eldan Hildesheim <i...@eldanet.com> +Alexander Wels
>>>>> <aw...@redhat.com> +Greg Sheremeta <gsher...@redhat.com>
>>>>>
>>>>> On Fri, May 5, 2017 at 2:32 AM Martin Perina <mper...@redhat.com>
>>>>> wrote:
>>>>>
>>>>>> On Thu, May 4, 2017 at 1:13 PM, Nir Soffer <nsof...@redhat.com> wr
>>>>>> ote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, May 4, 2017 at 4:26 PM Evgheni Dereveanchin <
>>>>>>> edere...@redhat.com> wrote:
>>>>>>>
>>>>>>>> Thanks everyone for the great feedback!
>>>>>>>>
>>>>>>>> So there's two options I see now:
>>>>>>>> 1) keep the default header scheme with white background, just add
>>>>>>>> the project logo into the corner
>>>>>>>> 2) try to adapt to the Patternfly scheme as used in oVirt's Admin
>>>>>>>> UI currently.
>>>>>>>>
>>>>>>>> I've swapped the header background color to #393f45 as used in
>>>>>>>> oVirt for a quick test:
>>>>>>>> https://gerrit-staging.phx.ovirt.org/
>>>>>>>>
>>>>>>>
>>>>>>> Looks good!
>>>>>>>
>>>>>>
>>>>>> ​Much better for my eyes now, thanks a lot!
>>>>>> ​
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> The oVirt logo needs little more space around it, and it also should
>>>>>>> be centered vertically.
>>>>>>> Modifying the logo margin to 8px and width to 108px works for me
>>>>>>> using chrome,
>>>>>>> see attached screenshot.
>>>>>>>
>>>>>>> 
>>>>>>>
>>>>>>> Nir
>>>>>>>
>>>>>>> Is this more readable? If yes - I can continue working in this
>>

Re: [ovirt-devel] Ansible Help Requested

[Phillip Bailey]

On Mon, Oct 2, 2017 at 8:52 AM, Simone Tiraboschi <stira...@redhat.com>
wrote:

>
>
> On Mon, Oct 2, 2017 at 2:40 PM, Phillip Bailey <phbai...@redhat.com>
> wrote:
>
>> Yaniv,
>>
>> The goal with the storage requirement is to verify connectivity of the
>> storage information provided by the user, as the input is being gathered
>> prior to running the setup process. The intent is to be able to provide
>> warnings to the user during the data collection process.
>>
>> Thanks for the CPU-related information. I was already pulling the CPU
>> model from the Ansible setup module. I needed help with verifying that the
>> model selected for the HE VM is compatible with the host's model. The link
>> you provided had the list available there, which helps tremendously. The
>> only issue I can see is that PPC models aren't included in that list.
>>
>
> The current hosted-engine-setup is a noarch rpm but currently we don't
> have any ppc engine-appliance to be deployed.
>

Ah, that makes more sense. Thanks! =)

>
>
>>
>> -
>>
>> Artyom,
>>
>> That project looks awesome and is very helpful. Thank you!
>>
>> -Phillip Bailey
>>
>> On Thu, Sep 28, 2017 at 1:37 AM, Artyom Lukianov <aluki...@redhat.com>
>> wrote:
>>
>>> Our infra team already deploy HE via ansible you can check their work
>>> under https://github.com/fusor/ansible-ovirt
>>>
>>> Best Regards
>>>
>>> On Wed, Sep 27, 2017 at 6:16 PM, Yaniv Kaul <yk...@redhat.com> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Sep 27, 2017 at 5:15 PM, Phillip Bailey <phbai...@redhat.com>
>>>> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I'm working on the new Cockpit hosted engine wizard and could use some
>>>>> input from all of you. One goal of this project is to move away from
>>>>> reliance on the existing OTOPI-based tools and towards an ansible-based
>>>>> approach.
>>>>>
>>>>> The items below are things we'd like to do using ansible, if possible.
>>>>> If any of you have existing plays or suggestions for the best way to use
>>>>> ansible to solve these problems, please let me know.
>>>>>
>>>>> Thanks!
>>>>>
>>>>>1. Verify provided storage settings for all allowable storage
>>>>>types.
>>>>>
>>>>>
>>>> I'm not sure I understand the requirement here.
>>>>
>>>>
>>>>>
>>>>>1.
>>>>>2. Verify compatibility of selected CPU type for the engine VM
>>>>>with the host's CPU
>>>>>
>>>>>
>>>> This is easy. See [1] for a simple Python code. In bash:
>>>> virsh -r capabilities |grep -m 1 ""
>>>>
>>>> Y.
>>>> [1] https://github.com/lago-project/lago/pull/323/files#diff
>>>> -1b557418847a737490a95d4841c6a362R96
>>>>
>>>> -Phillip Bailey
>>>>>
>>>>> ___
>>>>> Devel mailing list
>>>>> Devel@ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>>>
>>>>
>>>>
>>>> ___
>>>> Devel mailing list
>>>> Devel@ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>>
>>>
>>>
>>
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Ansible Help Requested

[Phillip Bailey]

Yaniv,

The goal with the storage requirement is to verify connectivity of the
storage information provided by the user, as the input is being gathered
prior to running the setup process. The intent is to be able to provide
warnings to the user during the data collection process.

Thanks for the CPU-related information. I was already pulling the CPU model
from the Ansible setup module. I needed help with verifying that the model
selected for the HE VM is compatible with the host's model. The link you
provided had the list available there, which helps tremendously. The only
issue I can see is that PPC models aren't included in that list.

-

Artyom,

That project looks awesome and is very helpful. Thank you!

-Phillip Bailey

On Thu, Sep 28, 2017 at 1:37 AM, Artyom Lukianov <aluki...@redhat.com>
wrote:

> Our infra team already deploy HE via ansible you can check their work
> under https://github.com/fusor/ansible-ovirt
>
> Best Regards
>
> On Wed, Sep 27, 2017 at 6:16 PM, Yaniv Kaul <yk...@redhat.com> wrote:
>
>>
>>
>> On Wed, Sep 27, 2017 at 5:15 PM, Phillip Bailey <phbai...@redhat.com>
>> wrote:
>>
>>> Hi all,
>>>
>>> I'm working on the new Cockpit hosted engine wizard and could use some
>>> input from all of you. One goal of this project is to move away from
>>> reliance on the existing OTOPI-based tools and towards an ansible-based
>>> approach.
>>>
>>> The items below are things we'd like to do using ansible, if possible.
>>> If any of you have existing plays or suggestions for the best way to use
>>> ansible to solve these problems, please let me know.
>>>
>>> Thanks!
>>>
>>>1. Verify provided storage settings for all allowable storage types.
>>>
>>>
>> I'm not sure I understand the requirement here.
>>
>>
>>>
>>>1.
>>>2. Verify compatibility of selected CPU type for the engine VM with
>>>the host's CPU
>>>
>>>
>> This is easy. See [1] for a simple Python code. In bash:
>> virsh -r capabilities |grep -m 1 ""
>>
>> Y.
>> [1] https://github.com/lago-project/lago/pull/323/files#diff
>> -1b557418847a737490a95d4841c6a362R96
>>
>> -Phillip Bailey
>>>
>>> ___
>>> Devel mailing list
>>> Devel@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>
>>
>>
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] Ansible Help Requested

[Phillip Bailey]

Hi all,

I'm working on the new Cockpit hosted engine wizard and could use some
input from all of you. One goal of this project is to move away from
reliance on the existing OTOPI-based tools and towards an ansible-based
approach.

The items below are things we'd like to do using ansible, if possible. If
any of you have existing plays or suggestions for the best way to use
ansible to solve these problems, please let me know.

Thanks!

   1. Verify provided storage settings for all allowable storage types.
   2. Verify compatibility of selected CPU type for the engine VM with the
   host's CPU

-Phillip Bailey
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel