From kanagaraj.rk at gmail.com  Sat Dec  1 17:25:15 2012
From: kanagaraj.rk at gmail.com (RK RK)
Date: Sat, 1 Dec 2012 22:55:15 +0530
Subject: New website live! Feedback welcome
In-Reply-To: <1761506442.36588886.1354313840898.JavaMail.root@redhat.com>
References: <50B8A433.1050209@redhat.com>
	<1761506442.36588886.1354313840898.JavaMail.root@redhat.com>
Message-ID: <CALVLwtbGEz-6eRoj7Hjp2_F9Ecyvnyq1YhiKBhPJNBGRiFUeRA@mail.gmail.com>

On Sat, Dec 1, 2012 at 3:47 AM, Doron Fediuck <dfediuck at redhat.com> wrote:

> ----- Original Message -----
> > From: "Dave Neary" <dneary at redhat.com>
> > To: announce at ovirt.org, "users" <users at ovirt.org>
> > Sent: Friday, November 30, 2012 2:18:59 PM
> > Subject: New website live! Feedback welcome
> >
> > Hi everyone,
> >
> > The new oVirt website is now live!
> >
> >    http://www.ovirt.org
> >
> > We have made some changes to the infrastructure (the website is now
> > running on MediaWiki: http://www.mediawiki.org on Red Hat's Platform
> > as
> > a Service offering OpenShift: https://openshift.redhat.com) and also
> > to
> > the look and feel. There is a new theme, designed and laid out by
> > Garrett Lesage, some new content to discover, and best of all, since
> > the
> > entire website is now a wiki, it will be much easier to maintain over
> > time.
> >
> > We have been careful to ensure that all of the old website links
> > redirect to appropriate pages on the new site. If you find any dead
> > links, or redirects which do not make sense, please let us know! And
> > as
> > the site has had limited exposure up to this point, we are happy to
> > hear
> > your feedback on things you like, and things we can improve.
> >
> > Thank you all for your support, assistance and understanding
> > throughout
> > this process!
> >
> > Regards,
> > Dave.
> >
> > --
> > Dave Neary - Community Action and Impact
> > Open Source and Standards, Red Hat - http://community.redhat.com
> > Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13
>
> Hi Dave,
> Wicked awesome ;)
> Looks so much better now.
>
> There are a few things I'm missing which may further improve the site;
>
> - In the community page, a section called (something in the spirit of)
> "Getting Help",
> which routes the users to the irc and users' list is much needed. It can
> even be one of
> the menu items in the main tool-bar.
>
> - The documentation page rightfully embeds 2 youtube clips. I think we can
> add a section
> for the youtube ovirt area, as these clips are documenting some of our
> features. We got several
> feedbacks that the clips are very helpful for understanding some of the
> concepts.
>
> - Going forward a forum would be nice, but need to see how it integrates
> with the lists.
> Possibly limit it to users forum?
>
> Thanks again!
> Doron
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
>

+1 beginning a oVirt forum will be much better.

-- 

With Regards,
RK,
+91 9840483044
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20121201/0d172d76/attachment.html>

From lpeer at redhat.com  Sun Dec  2 09:58:42 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Sun, 02 Dec 2012 11:58:42 +0200
Subject: integrating with quantum - proposal
In-Reply-To: <50B84FBA.6050307@redhat.com>
References: <50B37781.3030508@redhat.com> <50B84FBA.6050307@redhat.com>
Message-ID: <50BB2652.2090409@redhat.com>

On 30/11/12 08:18, Itamar Heim wrote:
> On 11/26/2012 09:06 AM, Livnat Peer wrote:
>> Hi Guys,
>> I'm about to send the proposal I worked on with Kolesnik to the list.
>>
>> Any political/other objections?
>>
>> http://wiki.ovirt.org/wiki/Quantum_IPAM_Integration
>>
>> We are starting to work on a POC to find the issues we missed in our
>> research so far, sending this to the list can get the discussion going.
>>
>> Livnat
>>
> 
> seems like an interesting solution, moving the problem of central dhcp
> to a distributed dhcp approach.
> 

Itamar,
Thanks for your input, specific replies in-context.

> so iiuc:
> - a per network config to specify if to enable IPAM on the logical
>   network.

yes (assuming that by config you mean property).

> - ability to specify the ip address ranges per logical network?

yes,
We did not look into the specific details yes but generally we expect to
model many of the properties that can be configured via DHCP server and
are mapped in the Quantum's Subnet entity (dns_nameservers, gateway_ip
etc.).
http://wiki.openstack.org/Quantum/APIv2-specification#Subnet

> - would we be able to set a policy at VM (or vnic) level to specify if
>   the vnic is getting the IP from the IPAM, or not?

If there is a use case for that, then why not.
In addition we will add support to specify static IP per vNIC by the
user (when IPAM is enabled on the network).

> - do we expect another mode of IP allocation (via the payload)?

AFAIU configuring IP via the payload is like defining a static IP not
via the engine (from IPAM POV). The engine will find about it via the
guest-agent report.

I guess the question hidden here is very similar to your previous
question, will we support overriding IPAM policy on a vNIC level which
enables setting IP addresses on a network via other means like the
payload (while for other VMs on that network you'd like to get a DHCP
service from oVirt).

In this context (aiming for a more generic IPAM modeling in oVirt) what
we did look at, is integration with Foreman smart-proxy [1]. It also
provides support for DHCP capabilities, but more for the use case of
having a DHCP server defined in your organization and you'd like oVirt
to integrate with it. This part of our work is still on-going, we'll
share ideas after we work on it some more.

[1] https://github.com/theforeman/smart-proxy/tree/develop/lib/proxy/dhcp

> - iiuc, quantum would be the one allocating the ip addresses
>   themselves. i assume there is an API allowing engine to get these ip
>   addresses back to show to admin/user?

In fact this is up to the Quantum plugin to implement. When creating a
Port in Quantum the plugin should allocate an IP for the port as part of
it's implementation (only if DHCP is enabled or subnet defined on the
network).
There is an implementation for the IP address allocation in
QuantumDbPluginV2 (_generate_ip) so the oVirt plugin can reuse the code
from there but we did not look into the specifics of the implementation yet.

Anyway the IP address allocated is part of the Port entity, we can
always query Quantum for the port details and get the IP. Or in the case
of using the oVirt plugin we can have another way to get this
information - however we want to avoid designing the integration around
the specific usage of oVirt plugin so when we get to the more detailed
design we'll have to look into our options there.

> - in ec2, the ip address changes every boot. do we expect the IP to be
>   reserved per mac address, or to be released when the VM goes down
>   (not sure what's the default IPAM behavior).
>   i could be confusing the IP behavior of the floating (public) IPs in
>   ec2 with the private IPs (which may be durable.

The release of the IP address is tightly coupled with the existence of
the Port entity in Quantum. As long as the Port is not deleted the IP is
reserved.
In our modeling we though to create a port in quantum on VM-start and
remove the port on VM-stop, which means for each VM boot (via the
engine) we'll get a new IP allocated, this correlates nicely with DHCP
behavior.
For statically defined addresses - I guess we'll have to keep the port
in Quantum for as long as the VM is defined in the engine - we need to
give it some more thought.

> - we'll need to think about the deployment aspects of qunatum service
>   and its agents.

of course

> - you are designing a "configuration api" by changing the qunatum
>   config and restarting the service. as the config file format may
> change, it may make sense to put a wrapper script around config changes,
> so the implementation of the required config could be change as qunatum
> evolves.

We did not give it a lot of though at this point, obviously something to
consider as part of stabilizing this integration.

> 
> looking forward to see something working from all of this.
> 
> Thanks,
>    Itamar



From kwade at redhat.com  Mon Dec  3 08:12:22 2012
From: kwade at redhat.com (Karsten 'quaid' Wade)
Date: Mon, 03 Dec 2012 00:12:22 -0800
Subject: New website live! Feedback welcome
In-Reply-To: <1761506442.36588886.1354313840898.JavaMail.root@redhat.com>
References: <1761506442.36588886.1354313840898.JavaMail.root@redhat.com>
Message-ID: <50BC5EE6.5090100@redhat.com>

On 11/30/2012 02:17 PM, Doron Fediuck wrote:

> 
> - Going forward a forum would be nice, but need to see how it integrates with the lists.
> Possibly limit it to users forum?

We could try Mailman 3 beta with the new forum-like archives. Here's an
update from 17 October:

http://aurelien.bompard.org/post/2012/10/17/Progress-on-HyperKitty

I was thinking of trying out a beta installation, perhaps we could find
a way to have it interface with the users@ mailing list? We can look in
to this next week.

- Karsten
-- 
Karsten 'quaid' Wade, Sr. Analyst - Community Growth
http://TheOpenSourceWay.org  .^\  http://community.redhat.com
@quaid (identi.ca/twitter/IRC)  \v'  gpg: AD0E0C41

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20121203/4d364ad4/attachment.sig>

From dneary at redhat.com  Mon Dec  3 10:26:21 2012
From: dneary at redhat.com (Dave Neary)
Date: Mon, 03 Dec 2012 11:26:21 +0100
Subject: [RFC] oVirtLive image
In-Reply-To: <20121202073825.GA2099@redhat.com>
References: <50ACEC85.9040700@redhat.com> <50AD4FC0.1010501@redhat.com>
	<50B76C69.2010907@redhat.com> <50B77A4A.9070004@redhat.com>
	<20121202073825.GA2099@redhat.com>
Message-ID: <50BC7E4D.5060807@redhat.com>

Hi,

On 12/02/2012 08:38 AM, Shahar Havivi wrote:
> Please update when we can update the wiki.
> Thanks.

You can update it right now - we unfroze the wiki on Friday morning at 1 
am CET/2am IST. You can log in through the "log in" link at the bottom 
of every page, username and password are the same as the old wiki, and 
except for the front page and "Develop", "Documentation", "Community" 
and "Download", which are protected and are administrator-only for 
editing, the entire wiki is open.

Cheers,
Dave.

-- 
Dave Neary - Community Action and Impact
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13


From agl at us.ibm.com  Mon Dec  3 14:13:26 2012
From: agl at us.ibm.com (Adam Litke)
Date: Mon, 3 Dec 2012 08:13:26 -0600
Subject: New website live! Feedback welcome
In-Reply-To: <50B8A433.1050209@redhat.com>
References: <50B8A433.1050209@redhat.com>
Message-ID: <20121203141326.GC4798@aglitke>

Great new look and I love how everything is organized.  Thanks for doing this!
I have one suggestion which you probably are already working on.  When the oVirt
on a stick project is ready, I would love to see it featured prominently at the
top of the downloads page.

On Fri, Nov 30, 2012 at 01:18:59PM +0100, Dave Neary wrote:
> Hi everyone,
> 
> The new oVirt website is now live!
> 
>   http://www.ovirt.org
> 
> We have made some changes to the infrastructure (the website is now
> running on MediaWiki: http://www.mediawiki.org on Red Hat's Platform
> as a Service offering OpenShift: https://openshift.redhat.com) and
> also to the look and feel. There is a new theme, designed and laid
> out by Garrett Lesage, some new content to discover, and best of
> all, since the entire website is now a wiki, it will be much easier
> to maintain over time.
> 
> We have been careful to ensure that all of the old website links
> redirect to appropriate pages on the new site. If you find any dead
> links, or redirects which do not make sense, please let us know! And
> as the site has had limited exposure up to this point, we are happy
> to hear your feedback on things you like, and things we can improve.
> 
> Thank you all for your support, assistance and understanding
> throughout this process!
> 
> Regards,
> Dave.
> 
> -- 
> Dave Neary - Community Action and Impact
> Open Source and Standards, Red Hat - http://community.redhat.com
> Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13
> _______________________________________________
> Announce mailing list
> Announce at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/announce
> 

-- 
Adam Litke <agl at us.ibm.com>
IBM Linux Technology Center



From dneary at redhat.com  Mon Dec  3 15:42:28 2012
From: dneary at redhat.com (Dave Neary)
Date: Mon, 03 Dec 2012 16:42:28 +0100
Subject: WARNING: Short outage of www.ovirt.org in 1h (15:30 UTC)
Message-ID: <50BCC864.1040400@redhat.com>

Hi all,

To resolve a critical issue with the new website 
(http://ovirt.org/pagename links are not getting correctly redirected to 
http://www.ovirt.org/pagename) we will be committing a change in the 
server configuration, which will restart the service.

This will result in a short (~30s) outage.

To help avoid any loss of work, we will be announcing critical changes 
such as this with one hour's notice.

Thank you for your understanding!

Regards,
Dave.
-- 
Dave Neary - Community Action and Impact
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13


From shaharh at redhat.com  Sun Dec  2 07:38:26 2012
From: shaharh at redhat.com (Shahar Havivi)
Date: Sun, 2 Dec 2012 09:38:26 +0200
Subject: [RFC] oVirtLive image
In-Reply-To: <50B77A4A.9070004@redhat.com>
References: <50ACEC85.9040700@redhat.com> <50AD4FC0.1010501@redhat.com>
	<50B76C69.2010907@redhat.com> <50B77A4A.9070004@redhat.com>
Message-ID: <20121202073825.GA2099@redhat.com>

On 29.11.12 16:07, Dave Neary wrote:
> Hi Itamar,
> 
> On 11/29/2012 03:08 PM, Itamar Heim wrote:
> >don't remember seeing any comments against this. created the repo.
> >moran, please work with dave to add it to:
> >http://www.ovirt.org/project/subprojects/
> 
> As you may have seen on infra@ and elsewhere, we are working hard to
> migrate to the new website before the end of the month. I'll touch
> base with Moran, but normally, from this evening we will be migrated
> to the new wiki-based website running on OpenShift, which will mean
> that anyone will be able to edit the "Subprojects" page.
> 
> Given how close we are to moving, I do not plan on making any edits
> in the wordpress site from now on.
> 
> Thanks,
> Dave.
Hi,
Please update when we can update the wiki.
Thanks.
> -- 
> Dave Neary - Community Action and Impact
> Open Source and Standards, Red Hat - http://community.redhat.com
> Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13


From kwade at redhat.com  Mon Dec  3 22:59:06 2012
From: kwade at redhat.com (Karsten 'quaid' Wade)
Date: Mon, 03 Dec 2012 14:59:06 -0800
Subject: WARNING: Short outage of www.ovirt.org in 1h (15:30 UTC)
In-Reply-To: <50BCC864.1040400@redhat.com>
References: <50BCC864.1040400@redhat.com>
Message-ID: <50BD2EBA.3010501@redhat.com>

On 12/03/2012 07:42 AM, Dave Neary wrote:
> Hi all,
> 
> To resolve a critical issue with the new website
> (http://ovirt.org/pagename links are not getting correctly redirected to
> http://www.ovirt.org/pagename) we will be committing a change in the
> server configuration, which will restart the service.

This problem is now resolved. ovirt.org/$pagename links should now
redirect to www.ovirt.org/$pagename. Let us know if you see anything
still not working.

> This will result in a short (~30s) outage.
> 
> To help avoid any loss of work, we will be announcing critical changes
> such as this with one hour's notice.

We ended up resolving this without an outage, as the correction needed
to be made where the site did not need to be restarted.

As Dave pointed out, when we have a critical need to restart services
that may affect any of you, we'll try to give an hour notice. Rarely
there won't be time for a notice, for the most part we can give one hour
notice for critical and 24-hour notice for non-critical service
restarts. The Infra team will work on a policy for this and publish it
for review.

Thanks - Karsten
-- 
Karsten 'quaid' Wade, Sr. Analyst - Community Growth
http://TheOpenSourceWay.org  .^\  http://community.redhat.com
@quaid (identi.ca/twitter/IRC)  \v'  gpg: AD0E0C41

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20121203/01943873/attachment.sig>

From iheim at redhat.com  Mon Dec  3 23:50:13 2012
From: iheim at redhat.com (Itamar Heim)
Date: Tue, 04 Dec 2012 01:50:13 +0200
Subject: Move of www.ovirt.org
In-Reply-To: <50B9014D.2000201@redhat.com>
References: <50B9014D.2000201@redhat.com>
Message-ID: <50BD3AB5.40107@redhat.com>

On 11/30/2012 08:56 PM, Karsten 'quaid' Wade wrote:
> Since we were using the host that was www.ovirt.org for many things
> other than MediaWiki, you may find that some of your automated
> activities are going to fail.
>
> We set up a new hostname for these various resources that are currently
> hosted on linode01.ovirt.org, with redirects in place from www:
>
> http://resources.ovirt.org/releases
> http://resources.ovirt.org/meetings
> etc.
>
> As nothing else has changed about that host, you should be able to
> s/www/resources/g wherever you use it, and things will Just Work.
>
> If you run in to a snag, let us know - we may need to add an http
> rewrite rule, etc.
>
> - Karsten
>
>
>
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
>

very nice. especially the fact some of the wiki's are now organized and 
referenced from the "main" pages.

a question, how do we get all the "wiki" features back though?
especially:
1. the special pages
2. edit history of a page
3. subscribing to a page

Thanks,
    Itamar


From iheim at redhat.com  Mon Dec  3 23:53:52 2012
From: iheim at redhat.com (Itamar Heim)
Date: Tue, 04 Dec 2012 01:53:52 +0200
Subject: RFC: oVirt NetApp workshop Call for Content
In-Reply-To: <50B8C817.3060106@redhat.com>
References: <50B8C817.3060106@redhat.com>
Message-ID: <50BD3B90.1090807@redhat.com>

On 11/30/2012 04:52 PM, Dave Neary wrote:
> Hi all,
>
> I just put a draft call for content in a new page for the NetApp
> workshop on the wiki: http://www.ovirt.org/NetApp_Workshop_January_2013
>
> The call for contents is basically a copy of the topic list from the KVM
> Forum/oVirt Workshop in Barcelona. Some points to note:
> * I set the deadline close, so that we could notify speakers before the
> holidays, and allow people coming from further away to organise travel
> arrangements. Is 2 weeks for a Call for Content enough?
> * We will re-use the workshop-pc mailing list for proposals and
> discussion. There was an open discussion point about what our
> subscription and posting policy should be for the list - I suggest that
> non-members may post to the list, and anyone can subscribe.

with the amount of spam on other lists, please have this one moderated 
as well.
i haven't seen many/any CFP lists which are open on their discussions on 
papers, rather just accepted/not accepted in the end?

>
> I would like to actively reach out to some oVirt users and partners to
> ensure that we have a diverse set of content for the conference - I
> would expecially like to hear some interesting case studies about the
> ways that oVirt is being used!
>
> Can I get some comments on this quickly, please? If it is acceptable, I
> would like to push it more widely this evening.
>
> Thanks,
> Dave.
>
> Call for Content
>
> We are actively seeking speakers for this workshop. We are interested in
> talks in the following areas:
>
>   *  Case studies of oVirt deployments
>   *  Using oVirt effectively
>   *  oVirt Project Roadmaps
>   *  Deep dives into features/areas
>   *  Deep dives into code/debugging/tuning
>   *  Integration and extensions
>   *  Components: engine, vdsm, node, sdk/cli, reports, mom, guest agent,
> etc.
>   *  Subjects: network, storage, vm life cycle, scheduling & sla,
> gluster, etc.
>   *  Packaging, installation and distributions
>   *  Community infrastructure and services
>
> Please submit talk proposals for review by sending a message to
> workshop-pc at ovirt.org. Your email should include your full name, speaker
> biography and your talk abstract. We will accept submissions through
> Friday, 14 December 2012 at 23:55 UTC. Speakers will be notified of
> acceptance by Friday, 21 December 2012.
>
> Accepted speakers should plan to submit their slides to the
> workshop-pc at ovirt.org mailing list no later than close of business on
> Friday, 18 January 2013.
>




From kwade at redhat.com  Tue Dec  4 02:43:38 2012
From: kwade at redhat.com (Karsten 'quaid' Wade)
Date: Mon, 03 Dec 2012 18:43:38 -0800
Subject: Move of www.ovirt.org
In-Reply-To: <50BD3AB5.40107@redhat.com>
References: <50B9014D.2000201@redhat.com> <50BD3AB5.40107@redhat.com>
Message-ID: <50BD635A.5090200@redhat.com>

On 12/03/2012 03:50 PM, Itamar Heim wrote:

> 
> a question, how do we get all the "wiki" features back though?
> especially:
> 1. the special pages
> 2. edit history of a page
> 3. subscribing to a page

Part of the skin is to hide the wiki features when you are not logged in.

If you look in the footer, there is a link to login. When you are logged
in, you'll see added layers/masks across the page - a header at the top
with dropdown menus, edit buttons appear, and so forth.

- Karsten
-- 
Karsten 'quaid' Wade, Sr. Analyst - Community Growth
http://TheOpenSourceWay.org  .^\  http://community.redhat.com
@quaid (identi.ca/twitter/IRC)  \v'  gpg: AD0E0C41

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20121203/cfeb487b/attachment.sig>

From iheim at redhat.com  Tue Dec  4 07:01:35 2012
From: iheim at redhat.com (Itamar Heim)
Date: Tue, 04 Dec 2012 09:01:35 +0200
Subject: Move of www.ovirt.org
In-Reply-To: <50BD635A.5090200@redhat.com>
References: <50B9014D.2000201@redhat.com> <50BD3AB5.40107@redhat.com>
	<50BD635A.5090200@redhat.com>
Message-ID: <50BD9FCF.2040408@redhat.com>

On 12/04/2012 04:43 AM, Karsten 'quaid' Wade wrote:
> On 12/03/2012 03:50 PM, Itamar Heim wrote:
>
>>
>> a question, how do we get all the "wiki" features back though?
>> especially:
>> 1. the special pages
>> 2. edit history of a page
>> 3. subscribing to a page
>
> Part of the skin is to hide the wiki features when you are not logged in.
>
> If you look in the footer, there is a link to login. When you are logged
> in, you'll see added layers/masks across the page - a header at the top
> with dropdown menus, edit buttons appear, and so forth.
>
> - Karsten
>

thanks.
I am logged in.
but how do i see the 'special pages' or the edit history of current 
page, or flag to subscribe/follow to this page?

thanks,
    ITamar


From lpeer at redhat.com  Tue Dec  4 07:07:03 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Tue, 04 Dec 2012 09:07:03 +0200
Subject: Move of www.ovirt.org
In-Reply-To: <50BD9FCF.2040408@redhat.com>
References: <50B9014D.2000201@redhat.com> <50BD3AB5.40107@redhat.com>
	<50BD635A.5090200@redhat.com> <50BD9FCF.2040408@redhat.com>
Message-ID: <50BDA117.80302@redhat.com>

On 04/12/12 09:01, Itamar Heim wrote:
> On 12/04/2012 04:43 AM, Karsten 'quaid' Wade wrote:
>> On 12/03/2012 03:50 PM, Itamar Heim wrote:
>>
>>>
>>> a question, how do we get all the "wiki" features back though?
>>> especially:
>>> 1. the special pages
>>> 2. edit history of a page
>>> 3. subscribing to a page
>>
>> Part of the skin is to hide the wiki features when you are not logged in.
>>
>> If you look in the footer, there is a link to login. When you are logged
>> in, you'll see added layers/masks across the page - a header at the top
>> with dropdown menus, edit buttons appear, and so forth.
>>
>> - Karsten
>>
> 
> thanks.
> I am logged in.
> but how do i see the 'special pages' or the edit history of current
> page, or flag to subscribe/follow to this page?

Above the top panel (where you can find the edit button) there is a
toolbox drop-down, there you can find the 'special pages' and 'Related
Changes'. on the top right corner you can find your name with a
drop-down there you can find your watch list, preferences and contributions.



> 
> thanks,
>    ITamar
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch



From iheim at redhat.com  Tue Dec  4 07:11:47 2012
From: iheim at redhat.com (Itamar Heim)
Date: Tue, 04 Dec 2012 09:11:47 +0200
Subject: Move of www.ovirt.org
In-Reply-To: <50BDA117.80302@redhat.com>
References: <50B9014D.2000201@redhat.com> <50BD3AB5.40107@redhat.com>
	<50BD635A.5090200@redhat.com> <50BD9FCF.2040408@redhat.com>
	<50BDA117.80302@redhat.com>
Message-ID: <50BDA233.7080808@redhat.com>

On 12/04/2012 09:07 AM, Livnat Peer wrote:
> On 04/12/12 09:01, Itamar Heim wrote:
>> On 12/04/2012 04:43 AM, Karsten 'quaid' Wade wrote:
>>> On 12/03/2012 03:50 PM, Itamar Heim wrote:
>>>
>>>>
>>>> a question, how do we get all the "wiki" features back though?
>>>> especially:
>>>> 1. the special pages
>>>> 2. edit history of a page
>>>> 3. subscribing to a page
>>>
>>> Part of the skin is to hide the wiki features when you are not logged in.
>>>
>>> If you look in the footer, there is a link to login. When you are logged
>>> in, you'll see added layers/masks across the page - a header at the top
>>> with dropdown menus, edit buttons appear, and so forth.
>>>
>>> - Karsten
>>>
>>
>> thanks.
>> I am logged in.
>> but how do i see the 'special pages' or the edit history of current
>> page, or flag to subscribe/follow to this page?
>
> Above the top panel (where you can find the edit button) there is a
> toolbox drop-down, there you can find the 'special pages' and 'Related
> Changes'. on the top right corner you can find your name with a
> drop-down there you can find your watch list, preferences and contributions.

thanks, not sure if it is me or the l&f, but i didn't find it easy to 
notice it (blended with the browser tool bars i guess)


From lhawthor at redhat.com  Tue Dec  4 13:04:36 2012
From: lhawthor at redhat.com (Leslie Hawthorn)
Date: Tue, 04 Dec 2012 05:04:36 -0800
Subject: [Workshop-pc] RFC: oVirt NetApp workshop Call for Content
In-Reply-To: <50BD3B90.1090807@redhat.com>
References: <50B8C817.3060106@redhat.com> <50BD3B90.1090807@redhat.com>
Message-ID: <50BDF4E4.8070509@redhat.com>

On 12/03/2012 03:53 PM, Itamar Heim wrote:
> On 11/30/2012 04:52 PM, Dave Neary wrote:
>> Hi all,
>>
>> I just put a draft call for content in a new page for the NetApp
>> workshop on the wiki: http://www.ovirt.org/NetApp_Workshop_January_2013
>>
>> The call for contents is basically a copy of the topic list from the KVM
>> Forum/oVirt Workshop in Barcelona. Some points to note:
>> * I set the deadline close, so that we could notify speakers before the
>> holidays, and allow people coming from further away to organise travel
>> arrangements. Is 2 weeks for a Call for Content enough?
>> * We will re-use the workshop-pc mailing list for proposals and
>> discussion. There was an open discussion point about what our
>> subscription and posting policy should be for the list - I suggest that
>> non-members may post to the list, and anyone can subscribe.
>
> with the amount of spam on other lists, please have this one moderated 
> as well.
> i haven't seen many/any CFP lists which are open on their discussions 
> on papers, rather just accepted/not accepted in the end?
Unless I am very much mistaken, the list archives are private and posts 
by non-members are moderated.

http://lists.ovirt.org/mailman/listinfo/workshop-pc

Cheers,
LH
>
>>
>> I would like to actively reach out to some oVirt users and partners to
>> ensure that we have a diverse set of content for the conference - I
>> would expecially like to hear some interesting case studies about the
>> ways that oVirt is being used!
>>
>> Can I get some comments on this quickly, please? If it is acceptable, I
>> would like to push it more widely this evening.
>>
>> Thanks,
>> Dave.
>>
>> Call for Content
>>
>> We are actively seeking speakers for this workshop. We are interested in
>> talks in the following areas:
>>
>>   *  Case studies of oVirt deployments
>>   *  Using oVirt effectively
>>   *  oVirt Project Roadmaps
>>   *  Deep dives into features/areas
>>   *  Deep dives into code/debugging/tuning
>>   *  Integration and extensions
>>   *  Components: engine, vdsm, node, sdk/cli, reports, mom, guest agent,
>> etc.
>>   *  Subjects: network, storage, vm life cycle, scheduling & sla,
>> gluster, etc.
>>   *  Packaging, installation and distributions
>>   *  Community infrastructure and services
>>
>> Please submit talk proposals for review by sending a message to
>> workshop-pc at ovirt.org. Your email should include your full name, speaker
>> biography and your talk abstract. We will accept submissions through
>> Friday, 14 December 2012 at 23:55 UTC. Speakers will be notified of
>> acceptance by Friday, 21 December 2012.
>>
>> Accepted speakers should plan to submit their slides to the
>> workshop-pc at ovirt.org mailing list no later than close of business on
>> Friday, 18 January 2013.
>>
>
>
> _______________________________________________
> Workshop-pc mailing list
> Workshop-pc at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/workshop-pc


-- 
Leslie Hawthorn
Community Action and Impact
Open Source and Standards @ Red Hat

identi.ca/lh
twitter.com/lhawthorn



From dneary at redhat.com  Tue Dec  4 13:25:27 2012
From: dneary at redhat.com (Dave Neary)
Date: Tue, 04 Dec 2012 14:25:27 +0100
Subject: [Workshop-pc] RFC: oVirt NetApp workshop Call for Content
In-Reply-To: <50BDF4E4.8070509@redhat.com>
References: <50B8C817.3060106@redhat.com> <50BD3B90.1090807@redhat.com>
	<50BDF4E4.8070509@redhat.com>
Message-ID: <50BDF9C7.9000506@redhat.com>

Hi,

On 12/04/2012 02:04 PM, Leslie Hawthorn wrote:
> On 12/03/2012 03:53 PM, Itamar Heim wrote:
>> On 11/30/2012 04:52 PM, Dave Neary wrote:
>>> * We will re-use the workshop-pc mailing list for proposals and
>>> discussion. There was an open discussion point about what our
>>> subscription and posting policy should be for the list - I suggest that
>>> non-members may post to the list, and anyone can subscribe.
>>
>> with the amount of spam on other lists, please have this one moderated
>> as well.
>> i haven't seen many/any CFP lists which are open on their discussions
>> on papers, rather just accepted/not accepted in the end?
> Unless I am very much mistaken, the list archives are private and posts
> by non-members are moderated.
>
> http://lists.ovirt.org/mailman/listinfo/workshop-pc

I was suggestiong changing this - I don't think it's very nice, when 
you're sending a proposal for a presentation, to get a message saying 
"this email is being held in moderation". Can we change the moderation 
email to say "Thank you for your submission, we will get back to you 
shortly"? Otherwise, I would suggest that we not moderate email posted 
to the list, while retaining moderated membership and private archives.

We would run the risk of receiving spam through the list, but in 
conjunction with the planned spam filtering which Kevin proposed to put 
in place, and which Karsten will set him up to do, that might not be a 
problem for long.

Cheers,
Dave.


-- 
Dave Neary - Community Action and Impact
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13


From lhawthor at redhat.com  Tue Dec  4 13:33:30 2012
From: lhawthor at redhat.com (Leslie Hawthorn)
Date: Tue, 04 Dec 2012 05:33:30 -0800
Subject: [Workshop-pc] RFC: oVirt NetApp workshop Call for Content
In-Reply-To: <50BDF9C7.9000506@redhat.com>
References: <50B8C817.3060106@redhat.com> <50BD3B90.1090807@redhat.com>
	<50BDF4E4.8070509@redhat.com> <50BDF9C7.9000506@redhat.com>
Message-ID: <50BDFBAA.1040600@redhat.com>

On 12/04/2012 05:25 AM, Dave Neary wrote:
> Hi,
>
> On 12/04/2012 02:04 PM, Leslie Hawthorn wrote:
>> On 12/03/2012 03:53 PM, Itamar Heim wrote:
>>> On 11/30/2012 04:52 PM, Dave Neary wrote:
>>>> * We will re-use the workshop-pc mailing list for proposals and
>>>> discussion. There was an open discussion point about what our
>>>> subscription and posting policy should be for the list - I suggest 
>>>> that
>>>> non-members may post to the list, and anyone can subscribe.
>>>
>>> with the amount of spam on other lists, please have this one moderated
>>> as well.
>>> i haven't seen many/any CFP lists which are open on their discussions
>>> on papers, rather just accepted/not accepted in the end?
>> Unless I am very much mistaken, the list archives are private and posts
>> by non-members are moderated.
>>
>> http://lists.ovirt.org/mailman/listinfo/workshop-pc
>
> I was suggestiong changing this - I don't think it's very nice, when 
> you're sending a proposal for a presentation, to get a message saying 
> "this email is being held in moderation". Can we change the moderation 
> email to say "Thank you for your submission, we will get back to you 
> shortly"? Otherwise, I would suggest that we not moderate email posted 
> to the list, while retaining moderated membership and private archives.
Ah, thank you for the context. I am in complete agreement with you. 
Regarding changing the list autoreply re: moderation, I can imagine this 
is possible but Karsten would know better.

Karsten, thoughts?
>
> We would run the risk of receiving spam through the list, but in 
> conjunction with the planned spam filtering which Kevin proposed to 
> put in place, and which Karsten will set him up to do, that might not 
> be a problem for long.
>
> Cheers,
> Dave.
>
>


-- 
Leslie Hawthorn
Community Action and Impact
Open Source and Standards @ Red Hat

identi.ca/lh
twitter.com/lhawthorn



From dneary at redhat.com  Tue Dec  4 13:35:10 2012
From: dneary at redhat.com (Dave Neary)
Date: Tue, 04 Dec 2012 14:35:10 +0100
Subject: Call for Content: oVirt Workshop at NetApp HQ, 22-24 Jan 2013
Message-ID: <50BDFC0E.6060607@redhat.com>

Hi everyone,

We are actively seeking speakers for the oVirt workshop which will be 
held in NetApp's Sunnyvale, California headquarters on 22-24 January 
2013. We are interested in talks in the following areas:

*  Case studies of oVirt deployments
*  Using oVirt effectively
*  oVirt Project Roadmaps
*  Deep dives into features/areas
*  Deep dives into code/debugging/tuning
*  Integration and extensions
*  Components: engine, vdsm, node, sdk/cli, reports, mom, guest agent, etc.
*  Subjects: network, storage, vm life cycle, scheduling & sla, gluster, 
etc.
*  Packaging, installation and distributions
*  Community infrastructure and services

Please submit talk proposals for review by sending a message to 
workshop-pc at ovirt.org. Your email should include your full name, speaker 
biography and your talk abstract. We will accept submissions through 
Friday, 14 December 2012 at 23:55 UTC. Speakers will be notified of 
acceptance by Friday, 21 December 2012.

Accepted speakers should plan to submit their slides to the 
workshop-pc at ovirt.org mailing list no later than close of business on 
Friday, 18 January 2013.

Registration for the workshop will be opening soon, keep your eyes open 
for further announcements!

Thank you all for your participation!
-- 
Dave Neary - Community Action and Impact
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13


From kwade at redhat.com  Wed Dec  5 20:32:18 2012
From: kwade at redhat.com (Karsten 'quaid' Wade)
Date: Wed, 05 Dec 2012 12:32:18 -0800
Subject: [Workshop-pc] RFC: oVirt NetApp workshop Call for Content
In-Reply-To: <50BDFBAA.1040600@redhat.com>
References: <50B8C817.3060106@redhat.com> <50BD3B90.1090807@redhat.com>
	<50BDF4E4.8070509@redhat.com> <50BDF9C7.9000506@redhat.com>
	<50BDFBAA.1040600@redhat.com>
Message-ID: <50BFAF52.7050601@redhat.com>

On 12/04/2012 05:33 AM, Leslie Hawthorn wrote:
> On 12/04/2012 05:25 AM, Dave Neary wrote:
>>
>> I was suggestiong changing this - I don't think it's very nice, when
>> you're sending a proposal for a presentation, to get a message saying
>> "this email is being held in moderation". Can we change the moderation
>> email to say "Thank you for your submission, we will get back to you
>> shortly"? Otherwise, I would suggest that we not moderate email posted
>> to the list, while retaining moderated membership and private archives.
> Ah, thank you for the context. I am in complete agreement with you.
> Regarding changing the list autoreply re: moderation, I can imagine this
> is possible but Karsten would know better.

IIRC, it's set on this page:

http://lists.ovirt.org/mailman/admin/workshop-pc/privacy/sender
http://lists.ovirt.org/mailman/admin/workshop-pc/?VARHELP=privacy/sender/member_moderation_notice

Since I had the page open I went ahead and pasted in the above
suggestion from Dave.

It's y'all's mailing list, but IMO private archives, moderated incoming
email, and a nice moderation message should be sufficient. Also, the
first time you pass through an email from someone, be sure to add them
to the 'accept_these_members' list (with the flag in the moderation
interface.)

Currently, 'accept_these_members' has ^.* in the top, a regular
expression that should accept all incoming email. I just tested that,
and it works. Currently, all incoming emails are just accepted. If you
want to change that, remove the '^.*' regexp from the top of the
'accept_these_members' field. This is findable on the same
privacy/sender page as above.

- Karsten
-- 
Karsten 'quaid' Wade, Sr. Analyst - Community Growth
http://TheOpenSourceWay.org  .^\  http://community.redhat.com
@quaid (identi.ca/twitter/IRC)  \v'  gpg: AD0E0C41

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20121205/b38a03c1/attachment.sig>

From vincent at vanderkussen.org  Wed Dec  5 21:46:26 2012
From: vincent at vanderkussen.org (vincent at vanderkussen.org)
Date: Wed, 05 Dec 2012 22:46:26 +0100
Subject: Concerning Loadays 2013
Message-ID: <20121205224626.15444l2co26x8k36@horde.vanderkussen.org>

Hi all, 

As suggetsed by quiad on #ovirt i'm posting this here.

I helporganize an event in Belgium called Loadays. This will already be the fourth edition and we got positive feedback about the previous editions. 

The site from last year is still available on http://www.loadays.eu to give you an idea . The "official" website is available at http://www.loadays.org . The twitter account is @loadays

If someone is interested in giving a talk/workshop feel free to submit a proposal.

Thanks

Vincent 


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20121205/0cc66a9b/attachment.html>

From kwade at redhat.com  Wed Dec  5 22:10:19 2012
From: kwade at redhat.com (Karsten 'quaid' Wade)
Date: Wed, 05 Dec 2012 14:10:19 -0800
Subject: Metawiki content needed
Message-ID: <50BFC64B.4070603@redhat.com>

We have a few pages that are prominently linked from the website footer,
which are currently blank:

http://www.ovirt.org/oVirt_Wiki:Privacy_policy
http://www.ovirt.org/oVirt_Wiki:About
http://www.ovirt.org/oVirt_Wiki:General_disclaimer

This page is linked from the [[Special:RequestAccount]] page:

http://www.ovirt.org/oVirt_Wiki:Terms_of_Service

These are standard pages, we can fill them or redirect them elsewhere.

For example, should the terms of service and privacy policy be
redirected to this page?

http://www.ovirt.org/Licensing

(Hmm, doesn't seem quite right.)

What content should go in these pages?
-- 
Karsten 'quaid' Wade, Sr. Analyst - Community Growth
http://TheOpenSourceWay.org  .^\  http://community.redhat.com
@quaid (identi.ca/twitter/IRC)  \v'  gpg: AD0E0C41

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20121205/91d250ee/attachment.sig>

From kwade at redhat.com  Thu Dec  6 18:40:57 2012
From: kwade at redhat.com (Karsten 'quaid' Wade)
Date: Thu, 06 Dec 2012 10:40:57 -0800
Subject: Unplanned outage :: www.ovirt.org :: 2012-12-06
Message-ID: <50C0E6B9.5070800@redhat.com>

We just had an unplanned outage of the www.ovirt.org site. The site was
unavailable for about three minutes.

== Details ==

I got a new theme.css file from Garrett to make the topbar a bit more
obvious to logged-in users. But I didn't want to push it and restart the
app, which is the default OpenShift behavior.

OpenShift has a hot deploy feature, set by putting a marker (touching a
file) in .openshift/markers/hot_deploy. When the marker is in place
during a 'git push', OpenShift is not supposed to restart the service.
Ideally, just having the marker there is enough so that the very push
itself doesn't restart anything.

Unfortunately, things didn't work as expected. When I pushed the change,
the output indicated that it stopped the service despite the hot_deploy
marker, and then didn't restart the service because of the hot_deploy
marker. I had to remove the marker and do another push to get it to
start the service.

git push
Counting objects: 22, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (14/14), done.
Writing objects: 100% (14/14), 1.80 KiB, done.
Total 14 (delta 10), reused 0 (delta 0)
remote: restart_on_add=false
remote: Waiting for stop to finish
remote: Done
remote: restart_on_add=false
remote: ~/git/wiki.git ~/git/wiki.git
remote: ~/git/wiki.git
remote: Running .openshift/action_hooks/pre_build
remote: Running .openshift/action_hooks/build
remote: Running .openshift/action_hooks/deploy
remote: Database found, skipping build
remote: hot_deploy_added=false
remote: App will not be started due to presence of hot_deploy marker
remote: Running .openshift/action_hooks/post_deploy
To
ssh://847edb45aea84198838f915be6faa066 at wiki-ovirt.rhcloud.com/~/git/wiki.git/
   85d7d77..d9a1670  master -> master

== Affected services ===

* www.ovirt.org

=== Not-affected services ===

* lists.ovirt.org
* resources.ovirt.org

== Future plans ==

Make the hot deploy work during a planned outage window rather than
during the middle of the work day. When hot deploy is working, we should
have fewer occasions of restarting the website just because we want to
push a CSS, config, etc. change.

-- 
Karsten 'quaid' Wade, Sr. Analyst - Community Growth
http://TheOpenSourceWay.org  .^\  http://community.redhat.com
@quaid (identi.ca/twitter/IRC)  \v'  gpg: AD0E0C41

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20121206/5d837128/attachment.sig>

From dneary at redhat.com  Fri Dec  7 15:06:07 2012
From: dneary at redhat.com (Dave Neary)
Date: Fri, 07 Dec 2012 16:06:07 +0100
Subject: Metawiki content needed
In-Reply-To: <50BFC64B.4070603@redhat.com>
References: <50BFC64B.4070603@redhat.com>
Message-ID: <50C205DF.50200@redhat.com>

Hi Karsten,

I'm pretty sure that I wrote an "About the oVirt wiki" page, which 
oVirt_Wiki:About was redirecting to. I can't find it now... :-(

There is this page: http://www.ovirt.org/OVirt_wiki which needs to be 
written, and should be a description of the basics of using a wiki, 
creating an account, etc. I'd like that page to be linked to from the 
Community and Develop pages.

Cheers,
Dave.

On 12/05/2012 11:10 PM, Karsten 'quaid' Wade wrote:
> We have a few pages that are prominently linked from the website footer,
> which are currently blank:
>
> http://www.ovirt.org/oVirt_Wiki:Privacy_policy
> http://www.ovirt.org/oVirt_Wiki:About
> http://www.ovirt.org/oVirt_Wiki:General_disclaimer
>
> This page is linked from the [[Special:RequestAccount]] page:
>
> http://www.ovirt.org/oVirt_Wiki:Terms_of_Service
>
> These are standard pages, we can fill them or redirect them elsewhere.
>
> For example, should the terms of service and privacy policy be
> redirected to this page?
>
> http://www.ovirt.org/Licensing
>
> (Hmm, doesn't seem quite right.)
>
> What content should go in these pages?
>
>
>
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
>

-- 
Dave Neary - Community Action and Impact
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13


From lhawthor at redhat.com  Mon Dec 10 23:55:23 2012
From: lhawthor at redhat.com (Leslie Hawthorn)
Date: Mon, 10 Dec 2012 15:55:23 -0800
Subject: Planning for the oVirt NetApp Workshop
Message-ID: <50C6766B.7030800@redhat.com>

Hello everyone,

The oVirt NetApp Workshop event information page [0] is up to date with 
all information as we currently have. Please plan to submit to our Call 
for Papers and to register for the workshop - all help spreading the 
word about the CFP and registration is much appreciated.

A few open items:

- We have a meeting room blocked for a Board Meeting on Thursday, 24 
January from 8 AM to 1 PM. Board members can expect a formal invitation 
to follow and further details from Carl Trieloff. Please plan to save 
the date for the Board Meeting.

- We're currently working on USB sticks and other promotional items for 
the workshop. If folks have some suggestions or would like to weigh in 
on the options presented by Red Hat's promotional products supplier, 
please let me know off-list.

[0] - http://wiki.ovirt.org/NetApp_Workshop_January_2013

Any questions on the workshop, please let me know. Many thanks to Jon 
Benedict and the NetApp team for hosting our next community event!

Cheers,
LH

-- 
Leslie Hawthorn
Community Action and Impact
Open Source and Standards @ Red Hat

identi.ca/lh
twitter.com/lhawthorn



From dneary at redhat.com  Wed Dec 12 09:07:01 2012
From: dneary at redhat.com (Dave Neary)
Date: Wed, 12 Dec 2012 10:07:01 +0100
Subject: Registration open for the oVirt Workshop
Message-ID: <50C84935.7050909@redhat.com>

Hi everyone!

For those who have not heard the news, I'd like to let you know about 
the oVirt Workshop at NetApp's Sunnyvale Campus, and remind you about 
the close of the Call for Participation for the event.

The oVirt Project, developers of an integrated, open source 
virtualization platform built on the KVM hypervisor, invites all those 
with an interest in open virtualization to the project's next workshop, 
taking place at NetApp's Sunnyvale campus on January 22-24.

The workshop's three day agenda will cover installation and use of 
oVirt, integrating with oVirt though the platform's APIs, and 
contributing to development of the project.

Reserve your spot at this free event by registering at 
http://ovirtnetapp2013.eventbrite.com/, and see 
http://www.ovirt.org/NetApp_Workshop_January_2013 for more information.

We are actively seeking presenters who can talk about interesting ways 
in which they are using oVirt, or share integration stories. Please send 
proposals for talks to workshop-pc at ovirt.org before Friday 14th of 
December, 23:59 PST.

Thanks!
Dave.


-- 
Dave Neary - Community Action and Impact
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13


From kwade at redhat.com  Thu Dec 13 01:16:25 2012
From: kwade at redhat.com (Karsten 'quaid' Wade)
Date: Wed, 12 Dec 2012 17:16:25 -0800
Subject: What's going on with images on the wiki
Message-ID: <50C92C69.9050405@redhat.com>

== Summary ==

Since the migration to OpenShift, due to a misconfiguration of
MediaWiki, we were writing images uploaded to the wiki to a
non-persistent data store location.

This means that most images uploaded since the migration may have been
destroyed, including archives of past versions of images.

== What's next ==

Jason Brooks and I diagnosed the problem and fixed it last night. We
didn't completely figure out which images were removed, but it's likely
to be most or all the images since the migration.

For any images you still have -- possibly including older version of the
images -- we can likely reinsert them in to their (new) location in the
filesystem and MediaWiki will pick them up. (Older versions are stored
in 'images/archives/'. Depending on the trickiness of the problem, we
may be able to reinsert the archived images.)

Email me with details of what images you have, page names, and so forth.
I'll work to get each one back where it belongs. Feel free to file a
ticket on Trac at http://fedorahosted.org/ovirt to help keep track of
the details. Or you can reply with details (but not images)

If you've lost any work as a result of this mistake, please accept my
apology. It was a mistake that didn't show itself in testing
post-migration (which points to failings in the testing.)

== Questions and comments ==

It's possible we haven't optimized our solution from here. Feel free to
chime in with your thoughts and questions. (Please read the 'Details'
section below first.)

== Details ==

When I configured the MediaWiki instance on OpenShift, I made the
writeable 'images' directory a symlink to  what I thought was the
persistent data store location. This appears as 'wiki/data', where the
MediaWiki code and content live in 'wiki/php'.

cd wiki
ls -hal | grep images
 images => ../data

That is, 'wiki/php/images' was a symlink to 'wiki/data'.

(Un)fortunately, 'wiki' is all entirely in a git repository. That means
I copied the images from the old MediaWiki instance in to a git
repository that OpenShift uses to completely rewrite the folder
structure on the server every time the code is checked in ('git push'.)

As it happens, the true persistent data store is '../../data', that is,
one directory *above* the 'wiki' directory. When you put content in
there, it is not overwritten with each 'git push'.

What happened this week was I did an outage window on Monday to push a
change to the app to make it hot deployable. (I actually did the same
thing last week, but I don't know if anyone had uploaded any new images.)

When I did a 'git push' of my changes, I apparently overwrote the
'wiki/data/' directory with my older copy of the content. I did a 'git
pull' before pushing but nothing came down; I'm not sure why but I
believe it has to do with the way OpenShift is configured.

Since Monday night, people began noticing images broken, complaints on
making thumbnails, and so forth. Jason and I worked on the problem on
Tuesday and figured out the solution. He moved all the content to the
persistent data store (also, got our quota doubled to 2 GB as we were
almost at 1 GB), and removed the data from the git repo.

In the end, Jason added a build hook that i) makes sure the
'../../data/images' directory is present, then ii) creates the necessary
symlink in the 'wiki/' structure after the code is checked in.

The same was done for 'compiled_templates', which was previously a
symlink for the MediaWiki Widgets extension. (That symlink was also
incorrectly written, so it may have been part of problems with the new
Widgets extensions?)

Thank you for your understanding, and I apologize for the inconvenience.

- Karsten
-- 
Karsten 'quaid' Wade, Sr. Analyst - Community Growth
http://TheOpenSourceWay.org  .^\  http://community.redhat.com
@quaid (identi.ca/twitter/IRC)  \v'  gpg: AD0E0C41

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20121212/3bf4765d/attachment.sig>

From dfediuck at redhat.com  Thu Dec 13 13:26:50 2012
From: dfediuck at redhat.com (Doron Fediuck)
Date: Thu, 13 Dec 2012 08:26:50 -0500 (EST)
Subject: Upgrading to libvirt 1.0.0
In-Reply-To: <809817103.48781745.1355404923997.JavaMail.root@redhat.com>
Message-ID: <283661613.48783022.1355405210848.JavaMail.root@redhat.com>

Hi, 
in [1] you can see a list of code changes introduced to this libvirt version,
after some thinking was done in the area of CPU tuning.

This actually resolves an issue we saw this week, which causes a VM to be
killed by libvirt, if only partial cpu-pinning is specified in the UI.

For example, assume a guest with 2 vCPUs running on a host with 4 pCPUs.
The pinning the user specified is: 0#2, which means vCPU 0 should be pinned
to pCPU 2. Running this VM will cause libvirt to start the VM and immediately
kill it.

libvirt 1.0.0 seems to have this fixed, so I suggest vdsm should require
this version.

Thanks,
Doron


[1] http://www.redhat.com/archives/libvir-list/2012-October/msg00535.html


From smizrahi at redhat.com  Thu Dec 13 16:27:19 2012
From: smizrahi at redhat.com (Saggi Mizrahi)
Date: Thu, 13 Dec 2012 11:27:19 -0500 (EST)
Subject: Upgrading to libvirt 1.0.0
In-Reply-To: <283661613.48783022.1355405210848.JavaMail.root@redhat.com>
Message-ID: <1897610998.18150366.1355416039120.JavaMail.root@redhat.com>

Changing VDSM requirements is usually done with a patch as it's version specific.
You should send a patch changing the spec and referencing any VDSM bugs it fixes.

----- Original Message -----
> From: "Doron Fediuck" <dfediuck at redhat.com>
> To: "arch" <arch at ovirt.org>
> Sent: Thursday, December 13, 2012 8:26:50 AM
> Subject: Upgrading to libvirt 1.0.0
> 
> Hi,
> in [1] you can see a list of code changes introduced to this libvirt
> version,
> after some thinking was done in the area of CPU tuning.
> 
> This actually resolves an issue we saw this week, which causes a VM
> to be
> killed by libvirt, if only partial cpu-pinning is specified in the
> UI.
> 
> For example, assume a guest with 2 vCPUs running on a host with 4
> pCPUs.
> The pinning the user specified is: 0#2, which means vCPU 0 should be
> pinned
> to pCPU 2. Running this VM will cause libvirt to start the VM and
> immediately
> kill it.
> 
> libvirt 1.0.0 seems to have this fixed, so I suggest vdsm should
> require
> this version.
> 
> Thanks,
> Doron
> 
> 
> [1]
> http://www.redhat.com/archives/libvir-list/2012-October/msg00535.html
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


From smizrahi at redhat.com  Thu Dec 13 19:50:00 2012
From: smizrahi at redhat.com (Saggi Mizrahi)
Date: Thu, 13 Dec 2012 14:50:00 -0500 (EST)
Subject: integrating with quantum - proposal
In-Reply-To: <50B84FBA.6050307@redhat.com>
Message-ID: <515988586.18222739.1355428200543.JavaMail.root@redhat.com>

This design is kind of odd.
You send the config to the quantum server.
Then you ask vdsm to tell the quantum agent to read the configuration from the server.

The Quantum server looks a bit redundant.
Ideally you would just send the conf to VSDM that will push it to the Quantom Agent it in turn will configure the DHCP.
Alternatively, Quantum Server pushes the information to the agents.

Now, from what I understand Quantum is "pull based" because it needs to be agnostic to VM allocation.
This means that the actual design should be that when running a VM part of the information is the openstack network ID.
VDSM in turn gets the agent to get the configuration info and configure the network.

It seems like the setDHCP() can be implied when starting a VM.
Also setDHCP() is kind of a bad name for this method as it doesn't set the protocl.
setDHCPConfigration() maybe but I'd rather have setIMAPConfiguration() so it's a bit less specific about how things are implemented.

In any case, the flows described in the wiki are part free text part flow diagram part some sort of flow\sequence diagram hybrid.
This makes it a bit difficult for me to follow the entire process. I might just have gotten everything wrong :).
Also, it's unclear to me who actually configures the network.

On 11/26/2012 09:06 AM, Livnat Peer wrote:
> Hi Guys,
> I'm about to send the proposal I worked on with Kolesnik to the
> list.
>
> Any political/other objections?
>
> http://wiki.ovirt.org/wiki/Quantum_IPAM_Integration
>
> We are starting to work on a POC to find the issues we missed in
> our
> research so far, sending this to the list can get the discussion
> going.
>
> Livnat
>


From rgolan at redhat.com  Fri Dec 14 00:18:09 2012
From: rgolan at redhat.com (Roy Golan)
Date: Fri, 14 Dec 2012 02:18:09 +0200
Subject: KVM on IBM POWER (PPC64) support in vdsm and ovirt
In-Reply-To: <50A8CAC9.9090403@redhat.com>
References: <504CC616.60501@in.ibm.com> <50839EBA.1080301@redhat.com>
	<509A7B86.4050700@linux.vnet.ibm.com>	<509CA431.8080405@redhat.com>
	<50A1F141.9010500@redhat.com> <50A236E4.1070304@linux.vnet.ibm.com>
	<50A67925.1010704@linux.vnet.ibm.com> <50A8CAC9.9090403@redhat.com>
Message-ID: <50CA7041.2090802@redhat.com>

On 11/18/2012 01:47 PM, Itamar Heim wrote:
> On 11/16/2012 07:34 PM, Fernando Granha Jeronimo wrote:
>> On 11/13/2012 10:02 AM, Paulo de Rezende Pinatti wrote:
>>> On 11/13/2012 05:05 AM, Itamar Heim wrote:
>>>> On 11/09/2012 08:35 AM, Itamar Heim wrote:
>>>>> On 11/07/2012 04:17 PM, Paulo de Rezende Pinatti wrote:
>>>>>> Hello all,
>>>>>>
>>>>>> I have consolidated the ideas for enabling ppc64 in ovirt-engine 
>>>>>> in a
>>>>>> feature page:
>>>>>> http://wiki.ovirt.org/wiki/Features/Engine_support_for_PPC64
>>>>>>
>>>>>> Suggestions and comments are greatly appreciated.
>>>>>
>>>>> iiuc, the most obvious change to mention is addition of an 'arch' 
>>>>> field
>>>>> to cluster, which would affect the list of supported cpu families,
>>>>> etc.?
>>>>> (and to later know to filter all other aspects of entities based on
>>>>> this
>>>>> arch field)?
>>>>>
>>>>> list of possible arch's would be per cluster compatibility level.
>>>>> i'd expect default for API of this field to be x86_64 for backward
>>>>> compatibility, so it is not mandatory.
>>>>> I'd also prefer this field to be disabled or hidden if there is only
>>>>> one
>>>>> option available in it.
>>>>>
>>>>> it gets more complicated, as VMs can be moved around between 
>>>>> clusters,
>>>>> exported/imported, etc.
>>>>>
>>>>> you would need to validate a VM isn't moved to a cluster with a
>>>>> different arch, or imported into a cluster with a different arch as
>>>>> well.
>>>>> (probably more like that).
>>>>>
>>>>> i assume the config to filter device types per arch like the network
>>>>> devices is also for console (spice), audio, etc.
>>>>>
>>>>> the system already has the concept of filtering per cluster level, so
>>>>> filtering per cluster level and arch would mean reviewing all 
>>>>> places in
>>>>> code for that.
>>>>
>>>> I'm adding roy/omer/michal as the work on libosinfo (patches in
>>>> gerrit[1]) seems to make some of these changes not needed (if it is
>>>> merged).
>>>> rather just need to extend libosinfo with the information on ppc.
>>>>
>>>> for sure worth reviewing both approaches to make sure the chosen
>>>> solution benefits both and we collaborate on same end goal.
>>>
>>> thanks, we will check these patches and possibly change the approach
>>> to use libosinfo.
>>>
>> Hello,
>>
>> We have carefully analyzed the engine libosinfo patches and the
>> libosinfo itself to devise
>> our conclusion. During this process, we found the following key points:
>>
>>    * In order to have a clear notion of supported versions and devices,
>> we would
>>      need to populate libosinfo's xmls for qemu and for devices, as well
>> as implement logic in
>>      ovirt-engine to process the relationship between them. This would
>> be basically partially
>>      reimplement the lib itself. In addition, given that we are not
>> using the lib but actually processing
>>      the xmls directly there is no guarantee that their structure will
>> be preserved in the future,
>>      which in the mid/long term may lead to code changes in the engine
>> to adapt to it.
>
> I thought that is what roy's patches are doing?
> i agree about the concern if the xml is changing.
all of your concerns have been brought up. please have a look at the 
discussion around how to integrate with libosinfo
http://lists.ovirt.org/pipermail/arch/2012-September/000924.html
any comments about it would be appreciated.
>
>>    * Even if libosinfo had all the information we needed in the xmls, we
>> would still need to validate
>>      or filter values according to ovirt-engine's rules. For instance,
>> if the list of network devices
>>      for PowerKVM in libosinfo had 5 elements and the engine only
>> intended to support/expose 2 specific models,
>>      (for a given version for example) it has to be aware of these two
>> models, meaning that even using libosinfo
>>      we still need something in engine to validate them (which
>> reinforces Itamar's filter suggestion).
>
> good point - Roy, how would cluster level compatibility for features 
> would work in your libosinfo approach?
I'd have to keep a set of devices per arch as libosinfo doesn't cover that.
>
>
>>
>> The primary concern of libosinfo patches is focused on virtual machine
>> parameters validation based on OS.
>> With regard to Power KVM support it doesn't address other areas like
>> hypervisor/cluster validation logic.
>
> well, this could just be since it wasn't populated for a non x86_64 
> arch. would it make sense for you to discuss ppc support for libosinfo 
> regardless?
>
>> Based on that and the exposed in the previous items, an approach that
>> seems to make sense if the libosinfo patches
>> are merged is to keep the focus of libosinfo usage as it is and for the
>> other areas to use the suggested in the
>> PowerKVM feature page
>> (http://wiki.ovirt.org/wiki/Features/Engine_support_for_PPC64). This
>> would benefit both and
>> converge to a project's solution.
>>
>> Appreciate comments you may have.
>>
>> Kind regards,
>>>>
>>>> [1] some of the patches are:
>>>> http://gerrit.ovirt.org/9065
>>>> http://gerrit.ovirt.org/9063
>>>> http://gerrit.ovirt.org/9049
>>>>
>>>
>>> _______________________________________________
>>> Arch mailing list
>>> Arch at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/arch
>>>
>>
>> _______________________________________________
>> Arch mailing list
>> Arch at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/arch
>
>



From dneary at redhat.com  Fri Dec 14 14:52:43 2012
From: dneary at redhat.com (Dave Neary)
Date: Fri, 14 Dec 2012 15:52:43 +0100
Subject: Concerning Loadays 2013
In-Reply-To: <20121205224626.15444l2co26x8k36@horde.vanderkussen.org>
References: <20121205224626.15444l2co26x8k36@horde.vanderkussen.org>
Message-ID: <50CB3D3B.1040205@redhat.com>

Hi,

I would love to see us have a speaker at this conference.

Vincent, what is the level of the audience usually? Would the audience 
be more interested in an "overview of oVirt"? or more community outreach 
("how to get involved")?

I can think of a few potential speakers, if they're willing to try... 
Ewoud is the nearest community member to Brussels, but I am also very close.

When is the deadline for proposals?

Thanks,
Dave.

On 12/05/2012 10:46 PM, vincent at vanderkussen.org wrote:
> Hi all,
>
> As suggetsed by quiad on #ovirt i'm posting this here.
>
> I helporganize an event in Belgium called Loadays. This will already be
> the fourth edition and we got positive feedback about the previous
> editions.
>
> The site from last year is still available on http://www.loadays.eu to
> give you an idea . The "official" website is available at
> http://www.loadays.org . The twitter account is @loadays
>
> If someone is interested in giving a talk/workshop feel free to submit a
> proposal.
>
> Thanks
>
> Vincent
>
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
>
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
>

-- 
Dave Neary - Community Action and Impact
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13


From sgordon at redhat.com  Fri Dec 14 20:24:40 2012
From: sgordon at redhat.com (Steve Gordon)
Date: Fri, 14 Dec 2012 15:24:40 -0500 (EST)
Subject: [RFC] oVirtLive image
In-Reply-To: <20121202073825.GA2099@redhat.com>
Message-ID: <12815560.48008292.1355516680528.JavaMail.root@redhat.com>

----- Original Message -----
> From: "Shahar Havivi" <shaharh at redhat.com>
> To: "Dave Neary" <dneary at redhat.com>
> Cc: "infra" <infra at ovirt.org>, arch at ovirt.org
> Sent: Sunday, December 2, 2012 2:38:26 AM
> Subject: Re: [RFC] oVirtLive image
> 
> On 29.11.12 16:07, Dave Neary wrote:
> > Hi Itamar,
> > 
> > On 11/29/2012 03:08 PM, Itamar Heim wrote:
> > >don't remember seeing any comments against this. created the repo.
> > >moran, please work with dave to add it to:
> > >http://www.ovirt.org/project/subprojects/
> > 
> > As you may have seen on infra@ and elsewhere, we are working hard
> > to
> > migrate to the new website before the end of the month. I'll touch
> > base with Moran, but normally, from this evening we will be
> > migrated
> > to the new wiki-based website running on OpenShift, which will mean
> > that anyone will be able to edit the "Subprojects" page.
> > 
> > Given how close we are to moving, I do not plan on making any edits
> > in the wordpress site from now on.
> > 
> > Thanks,
> > Dave.
> Hi,
> Please update when we can update the wiki.
> Thanks.

Hi guys,

Two things here:

- The sub-projects wiki page still doesn't list this.
- The repo still doesn't contain anything.

I had a look to see if I could edit the wiki page myself but I can't even see how to log in with the new skin (probably blind I guess).

Steve


From vincent at vanderkussen.org  Sat Dec 15 09:44:10 2012
From: vincent at vanderkussen.org (Vincent Van der Kussen)
Date: Sat, 15 Dec 2012 10:44:10 +0100
Subject: Concerning Loadays 2013
In-Reply-To: <50CB3D3B.1040205@redhat.com>
References: <20121205224626.15444l2co26x8k36@horde.vanderkussen.org>
	<50CB3D3B.1040205@redhat.com>
Message-ID: <20121215094410.GB3314@faramir.homebase.local>

On Fri, Dec 14, 2012 at 03:52:43PM +0100, Dave Neary wrote:

Hi, 


> Hi,
> 
> I would love to see us have a speaker at this conference.
> 
> Vincent, what is the level of the audience usually? Would the
> audience be more interested in an "overview of oVirt"? or more
> community outreach ("how to get involved")?

Most people are active in several open source projects and have a technical background. 
So a more in depth and practical overview + how to participate in the oVirt community would cover it. 
There's alway place (depending on the other talks/workshops of course) to do a workshop to show 
the technical/practical side of oVirt.

I think most people would like to know more about how oVirt handles storage, networking, does Gluster work?, etc..
> 
> I can think of a few potential speakers, if they're willing to
> try... Ewoud is the nearest community member to Brussels, but I am
> also very close.
> 
> When is the deadline for proposals?

Deadline is arounf 1st of March.

If you have any further questions you can always contact me.
> 
> Thanks,
> Dave.

Regards,
Vincent

> 
> On 12/05/2012 10:46 PM, vincent at vanderkussen.org wrote:
> >Hi all,
> >
> >As suggetsed by quiad on #ovirt i'm posting this here.
> >
> >I helporganize an event in Belgium called Loadays. This will already be
> >the fourth edition and we got positive feedback about the previous
> >editions.
> >
> >The site from last year is still available on http://www.loadays.eu to
> >give you an idea . The "official" website is available at
> >http://www.loadays.org . The twitter account is @loadays
> >
> >If someone is interested in giving a talk/workshop feel free to submit a
> >proposal.
> >
> >Thanks
> >
> >Vincent
> >
> >
> >----------------------------------------------------------------
> >This message was sent using IMP, the Internet Messaging Program.
> >
> >
> >_______________________________________________
> >Arch mailing list
> >Arch at ovirt.org
> >http://lists.ovirt.org/mailman/listinfo/arch
> >
> 
> -- 
> Dave Neary - Community Action and Impact
> Open Source and Standards, Red Hat - http://community.redhat.com
> Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13


From iheim at redhat.com  Tue Dec 18 22:32:21 2012
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 19 Dec 2012 00:32:21 +0200
Subject: Concerning Loadays 2013
In-Reply-To: <20121215094410.GB3314@faramir.homebase.local>
References: <20121205224626.15444l2co26x8k36@horde.vanderkussen.org>
	<50CB3D3B.1040205@redhat.com>
	<20121215094410.GB3314@faramir.homebase.local>
Message-ID: <50D0EEF5.6030303@redhat.com>

On 12/15/2012 11:44 AM, Vincent Van der Kussen wrote:
> On Fri, Dec 14, 2012 at 03:52:43PM +0100, Dave Neary wrote:
>
> Hi,
>
>
>> Hi,
>>
>> I would love to see us have a speaker at this conference.
>>
>> Vincent, what is the level of the audience usually? Would the
>> audience be more interested in an "overview of oVirt"? or more
>> community outreach ("how to get involved")?
>
> Most people are active in several open source projects and have a technical background.
> So a more in depth and practical overview + how to participate in the oVirt community would cover it.
> There's always place (depending on the other talks/workshops of course) to do a workshop to show
> the technical/practical side of oVirt.
>
> I think most people would like to know more about how oVirt handles storage, networking, does Gluster work?, etc..
>>
>> I can think of a few potential speakers, if they're willing to
>> try... Ewoud is the nearest community member to Brussels, but I am
>> also very close.
>>
>> When is the deadline for proposals?
>
> Deadline is arounf 1st of March.
>
> If you have any further questions you can always contact me.

sounds interesting, are you looking for 1-2 sessions, or more than that 
(intro, arch, ovirt-live hands-on session, etc.)?

thanks,
    Itamar




From vincent at vanderkussen.org  Wed Dec 19 11:51:39 2012
From: vincent at vanderkussen.org (Vincent Van der Kussen)
Date: Wed, 19 Dec 2012 12:51:39 +0100
Subject: Concerning Loadays 2013
In-Reply-To: <50D0EEF5.6030303@redhat.com>
References: <20121205224626.15444l2co26x8k36@horde.vanderkussen.org>
	<50CB3D3B.1040205@redhat.com>
	<20121215094410.GB3314@faramir.homebase.local>
	<50D0EEF5.6030303@redhat.com>
Message-ID: <20121219115139.GA5650@faramir.homebase.local>

On Wed, Dec 19, 2012 at 12:32:21AM +0200, Itamar Heim wrote:
> On 12/15/2012 11:44 AM, Vincent Van der Kussen wrote:
> >On Fri, Dec 14, 2012 at 03:52:43PM +0100, Dave Neary wrote:
> >
> >Hi,
> >
> >
> >>Hi,
> >>
> >>I would love to see us have a speaker at this conference.
> >>
> >>Vincent, what is the level of the audience usually? Would the
> >>audience be more interested in an "overview of oVirt"? or more
> >>community outreach ("how to get involved")?
> >
> >Most people are active in several open source projects and have a technical background.
> >So a more in depth and practical overview + how to participate in the oVirt community would cover it.
> >There's always place (depending on the other talks/workshops of course) to do a workshop to show
> >the technical/practical side of oVirt.
> >
> >I think most people would like to know more about how oVirt handles storage, networking, does Gluster work?, etc..
> >>
> >>I can think of a few potential speakers, if they're willing to
> >>try... Ewoud is the nearest community member to Brussels, but I am
> >>also very close.
> >>
> >>When is the deadline for proposals?
> >
> >Deadline is arounf 1st of March.
> >
> >If you have any further questions you can always contact me.
> 
> sounds interesting, are you looking for 1-2 sessions, or more than
> that (intro, arch, ovirt-live hands-on session, etc.)?
> 
> thanks,
>    Itamar

Hi, 

I suggest you send your proposals to cfp at loadays.org. We're quite flexible fitting everything
in the schedule.

Regards,
Vincent

> 
> 


From kwade at redhat.com  Wed Dec 19 23:07:59 2012
From: kwade at redhat.com (Karsten 'quaid' Wade)
Date: Wed, 19 Dec 2012 15:07:59 -0800
Subject: Maintenance outage :: lists.ovirt.org :: 2012-12-20 01:00 UTC
Message-ID: <50D248CF.4080505@redhat.com>

There is an outage of lists.ovirt.org for ten minutes to increase disk
space on the host.

The outage will occur at 2012-12-20 01:00 UTC. To view in your local time:

date -d '2012-12-20 01:00 UTC'

== Details ==

We are constantly nearly out of disk space on linode01.ovirt.org, which
hosts the Mailman and yum/download repositories.

As a stop-gap help, I've got 5 GB more of space I can put in to the host VM.

We plan to migrate this host to one of the Alter Way instances, probably
a VM running on one of the two physical machines. If possible, we'll
make this move soonest for both the Mailman and download repositories.

== Affected services ==

* lists.ovirt.org
* resources.ovirt.org
* httpd redirects of old URLs
* IRC bot

=== Not-affected services ==

* www.ovirt.org
* jenkins.ovirt.org
* gerrit.ovirt.org
* git.ovirt.org

== Future plans ==

Move services to a host with more space and capability, as part of the
Infra team general hosting plan.

-- 
Karsten 'quaid' Wade, Sr. Analyst - Community Growth
http://TheOpenSourceWay.org  .^\  http://community.redhat.com
@quaid (identi.ca/twitter/IRC)  \v'  gpg: AD0E0C41

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20121219/cfb51a64/attachment.sig>

From mpastern at redhat.com  Fri Dec 21 10:44:51 2012
From: mpastern at redhat.com (Michael Pasternak)
Date: Fri, 21 Dec 2012 12:44:51 +0200
Subject: [Engine-devel] [SUGGESTION] Defining a process for the new feature
	discussion/implementation.
In-Reply-To: <50D38DF1.7050809@redhat.com>
References: <1488374349.6339258.1356041523739.JavaMail.root@redhat.com>
	<50D38DF1.7050809@redhat.com>
Message-ID: <50D43DA3.2010300@redhat.com>

On 12/21/2012 12:15 AM, Itamar Heim wrote:
> On 12/21/2012 12:12 AM, Alon Bar-Lev wrote:
>>
>>
>> ----- Original Message -----
>>> From: "Itamar Heim" <iheim at redhat.com>
>>> To: "Michael Pasternak" <mpastern at redhat.com>
>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>>> Sent: Thursday, December 20, 2012 11:42:37 PM
>>> Subject: Re: [Engine-devel] [SUGGESTION] Defining a process for the new feature discussion/implementation.
>>>
>>> On 12/19/2012 03:08 PM, Michael Pasternak wrote:
>>>>
>>>> Hi All,
>>>>
>>>> In many cases OSS maintainers not always can be in the loop of
>>>> different threads what may
>>>> cause them missing important decisions being taken,
>>>>
>>>> As result later on during reviews of the patches they're not
>>>> accepting (already implemented)
>>>> features, what is causing not once for feature to be re-designed
>>>> and/or delayed, what is wrong
>>>> from the development cycle PoV.
>>>>
>>>> Therefore I'd like to suggest establishing dev-rules for the new
>>>> feature implementation,
>>>> what will make entire process much more easer for all of us:
>>>>
>>>> 1. discuss new feature on the mailing list
>>>> (requirements/constraints/etc.)
>>>> 2. summarise feature details in feature-doc
>>>> 3. send feature-doc to review to:
>>>>      3.1 ML (engine-devel)
>>>>      3.2 MG (mailing group of maintainers of the relevant layers)
>>>> 4. after feature-doc is accepted,
>>>>      4.1 implement the feature
>>>>      4.2 send it to gerrit for review to:
>>>>          4.2.1 lead maintainer/s (they will review/delegate it)
>>>>
>>>>
>>>> NOTE 3.2, 4.2.1 will require defining MGs such as:
>>>>         - engine-devel-core
>>>>         - engine-devel-ui
>>>>         - engine-devel-api
>>>>         - engine-devel-sdk
>>>>         - engine-devel-cli
>>>>         - engine-devel-vdsm ...
>>>>
>>>>
>>>> Thoughts?
>>>>
>>>
>>> i thought this is what we have the arch mailing list for, since any
>>> feature is going to cut through multiple layers/components, unless
>>> they
>>> are very specific, they should be sent to arch, and all maintainers
>>> should follow arch.
>>
>> What is missing is upstream bugzilla.
>>
>> A feature, after initiate stage should be represented with a bug.
>> The bug should be assigned to the right designated milestone.
>> All document references (including versions) should be attached or referred by the bug.
>> Dependency between features can be established using bug dependencies.
>> Status can be acquired from buzilla at any time, progress reports should be input into bugzilla.
>> Contact details for the feature can be acquired too, relevant and interested parties can be CCed explicitly.
>> I guess I can add more benefits.
>>
>> Mailing list is good for idea initiation, but not for lifecycle management, nor for people to join at implementation phase and understand why, how and when.
>>
>> Having upstream bugzilla will also help us plan ahead, and manage the break the project into smaller components, to assign core developers for each.
> 
> it still won't help tracking all relevant maintainers from rest api, ui, engine, vdsm saw the bug. we have multiple components.
> arch is mostly to cover cross component issues, such as features.

this is why i'm suggesting creating mailing-groups peer component,
feature owner knows what layers are involved and should be responsible to CC
relevant MGs in both BZ & thread.

> (or we could create a feature mailing list).

ML/MG peer feature is too much i think.

> 
> but i do agree we could use bugzilla for tracking features per version, if wiki isn't tracking this correctly.

+1


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From alonbl at redhat.com  Fri Dec 21 11:57:05 2012
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Fri, 21 Dec 2012 06:57:05 -0500 (EST)
Subject: [Engine-devel] [SUGGESTION] Defining a process for the new
	feature discussion/implementation.
In-Reply-To: <50D43DA3.2010300@redhat.com>
Message-ID: <652889674.6421746.1356091025982.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Michael Pasternak" <mpastern at redhat.com>
> To: "Itamar Heim" <iheim at redhat.com>
> Cc: "Alon Bar-Lev" <alonbl at redhat.com>, "engine-devel" <engine-devel at ovirt.org>, arch at ovirt.org
> Sent: Friday, December 21, 2012 12:44:51 PM
> Subject: Re: [Engine-devel] [SUGGESTION] Defining a process for the new feature discussion/implementation.
> 
> On 12/21/2012 12:15 AM, Itamar Heim wrote:
> > On 12/21/2012 12:12 AM, Alon Bar-Lev wrote:
> >>
> >>
> >> ----- Original Message -----
> >>> From: "Itamar Heim" <iheim at redhat.com>
> >>> To: "Michael Pasternak" <mpastern at redhat.com>
> >>> Cc: "engine-devel" <engine-devel at ovirt.org>
> >>> Sent: Thursday, December 20, 2012 11:42:37 PM
> >>> Subject: Re: [Engine-devel] [SUGGESTION] Defining a process for
> >>> the new feature discussion/implementation.
> >>>
> >>> On 12/19/2012 03:08 PM, Michael Pasternak wrote:
> >>>>
> >>>> Hi All,
> >>>>
> >>>> In many cases OSS maintainers not always can be in the loop of
> >>>> different threads what may
> >>>> cause them missing important decisions being taken,
> >>>>
> >>>> As result later on during reviews of the patches they're not
> >>>> accepting (already implemented)
> >>>> features, what is causing not once for feature to be re-designed
> >>>> and/or delayed, what is wrong
> >>>> from the development cycle PoV.
> >>>>
> >>>> Therefore I'd like to suggest establishing dev-rules for the new
> >>>> feature implementation,
> >>>> what will make entire process much more easer for all of us:
> >>>>
> >>>> 1. discuss new feature on the mailing list
> >>>> (requirements/constraints/etc.)
> >>>> 2. summarise feature details in feature-doc
> >>>> 3. send feature-doc to review to:
> >>>>      3.1 ML (engine-devel)
> >>>>      3.2 MG (mailing group of maintainers of the relevant
> >>>>      layers)
> >>>> 4. after feature-doc is accepted,
> >>>>      4.1 implement the feature
> >>>>      4.2 send it to gerrit for review to:
> >>>>          4.2.1 lead maintainer/s (they will review/delegate it)
> >>>>
> >>>>
> >>>> NOTE 3.2, 4.2.1 will require defining MGs such as:
> >>>>         - engine-devel-core
> >>>>         - engine-devel-ui
> >>>>         - engine-devel-api
> >>>>         - engine-devel-sdk
> >>>>         - engine-devel-cli
> >>>>         - engine-devel-vdsm ...
> >>>>
> >>>>
> >>>> Thoughts?
> >>>>
> >>>
> >>> i thought this is what we have the arch mailing list for, since
> >>> any
> >>> feature is going to cut through multiple layers/components,
> >>> unless
> >>> they
> >>> are very specific, they should be sent to arch, and all
> >>> maintainers
> >>> should follow arch.
> >>
> >> What is missing is upstream bugzilla.
> >>
> >> A feature, after initiate stage should be represented with a bug.
> >> The bug should be assigned to the right designated milestone.
> >> All document references (including versions) should be attached or
> >> referred by the bug.
> >> Dependency between features can be established using bug
> >> dependencies.
> >> Status can be acquired from buzilla at any time, progress reports
> >> should be input into bugzilla.
> >> Contact details for the feature can be acquired too, relevant and
> >> interested parties can be CCed explicitly.
> >> I guess I can add more benefits.
> >>
> >> Mailing list is good for idea initiation, but not for lifecycle
> >> management, nor for people to join at implementation phase and
> >> understand why, how and when.
> >>
> >> Having upstream bugzilla will also help us plan ahead, and manage
> >> the break the project into smaller components, to assign core
> >> developers for each.
> > 
> > it still won't help tracking all relevant maintainers from rest
> > api, ui, engine, vdsm saw the bug. we have multiple components.
> > arch is mostly to cover cross component issues, such as features.
> 
> this is why i'm suggesting creating mailing-groups peer component,
> feature owner knows what layers are involved and should be
> responsible to CC
> relevant MGs in both BZ & thread.

mailing group is something nobody can manage.
you can consider a group as all people who are CC to a bug.

> 
> > (or we could create a feature mailing list).
> 
> ML/MG peer feature is too much i think.
> 
> > 
> > but i do agree we could use bugzilla for tracking features per
> > version, if wiki isn't tracking this correctly.
> 
> +1
> 
> 
> --
> 
> Michael Pasternak
> RedHat, ENG-Virtualization R&D
> 


From mpastern at redhat.com  Sun Dec 23 06:25:23 2012
From: mpastern at redhat.com (Michael Pasternak)
Date: Sun, 23 Dec 2012 08:25:23 +0200
Subject: [Engine-devel] [SUGGESTION] Defining a process for the new feature
	discussion/implementation.
In-Reply-To: <652889674.6421746.1356091025982.JavaMail.root@redhat.com>
References: <652889674.6421746.1356091025982.JavaMail.root@redhat.com>
Message-ID: <50D6A3D3.7010701@redhat.com>

On 12/21/2012 01:57 PM, Alon Bar-Lev wrote:
> 
> 
> ----- Original Message -----
>> From: "Michael Pasternak" <mpastern at redhat.com>
>> To: "Itamar Heim" <iheim at redhat.com>
>> Cc: "Alon Bar-Lev" <alonbl at redhat.com>, "engine-devel" <engine-devel at ovirt.org>, arch at ovirt.org
>> Sent: Friday, December 21, 2012 12:44:51 PM
>> Subject: Re: [Engine-devel] [SUGGESTION] Defining a process for the new feature discussion/implementation.
>>
>> On 12/21/2012 12:15 AM, Itamar Heim wrote:
>>> On 12/21/2012 12:12 AM, Alon Bar-Lev wrote:
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Itamar Heim" <iheim at redhat.com>
>>>>> To: "Michael Pasternak" <mpastern at redhat.com>
>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>>>>> Sent: Thursday, December 20, 2012 11:42:37 PM
>>>>> Subject: Re: [Engine-devel] [SUGGESTION] Defining a process for
>>>>> the new feature discussion/implementation.
>>>>>
>>>>> On 12/19/2012 03:08 PM, Michael Pasternak wrote:
>>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> In many cases OSS maintainers not always can be in the loop of
>>>>>> different threads what may
>>>>>> cause them missing important decisions being taken,
>>>>>>
>>>>>> As result later on during reviews of the patches they're not
>>>>>> accepting (already implemented)
>>>>>> features, what is causing not once for feature to be re-designed
>>>>>> and/or delayed, what is wrong
>>>>>> from the development cycle PoV.
>>>>>>
>>>>>> Therefore I'd like to suggest establishing dev-rules for the new
>>>>>> feature implementation,
>>>>>> what will make entire process much more easer for all of us:
>>>>>>
>>>>>> 1. discuss new feature on the mailing list
>>>>>> (requirements/constraints/etc.)
>>>>>> 2. summarise feature details in feature-doc
>>>>>> 3. send feature-doc to review to:
>>>>>>      3.1 ML (engine-devel)
>>>>>>      3.2 MG (mailing group of maintainers of the relevant
>>>>>>      layers)
>>>>>> 4. after feature-doc is accepted,
>>>>>>      4.1 implement the feature
>>>>>>      4.2 send it to gerrit for review to:
>>>>>>          4.2.1 lead maintainer/s (they will review/delegate it)
>>>>>>
>>>>>>
>>>>>> NOTE 3.2, 4.2.1 will require defining MGs such as:
>>>>>>         - engine-devel-core
>>>>>>         - engine-devel-ui
>>>>>>         - engine-devel-api
>>>>>>         - engine-devel-sdk
>>>>>>         - engine-devel-cli
>>>>>>         - engine-devel-vdsm ...
>>>>>>
>>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>
>>>>> i thought this is what we have the arch mailing list for, since
>>>>> any
>>>>> feature is going to cut through multiple layers/components,
>>>>> unless
>>>>> they
>>>>> are very specific, they should be sent to arch, and all
>>>>> maintainers
>>>>> should follow arch.
>>>>
>>>> What is missing is upstream bugzilla.
>>>>
>>>> A feature, after initiate stage should be represented with a bug.
>>>> The bug should be assigned to the right designated milestone.
>>>> All document references (including versions) should be attached or
>>>> referred by the bug.
>>>> Dependency between features can be established using bug
>>>> dependencies.
>>>> Status can be acquired from buzilla at any time, progress reports
>>>> should be input into bugzilla.
>>>> Contact details for the feature can be acquired too, relevant and
>>>> interested parties can be CCed explicitly.
>>>> I guess I can add more benefits.
>>>>
>>>> Mailing list is good for idea initiation, but not for lifecycle
>>>> management, nor for people to join at implementation phase and
>>>> understand why, how and when.
>>>>
>>>> Having upstream bugzilla will also help us plan ahead, and manage
>>>> the break the project into smaller components, to assign core
>>>> developers for each.
>>>
>>> it still won't help tracking all relevant maintainers from rest
>>> api, ui, engine, vdsm saw the bug. we have multiple components.
>>> arch is mostly to cover cross component issues, such as features.
>>
>> this is why i'm suggesting creating mailing-groups peer component,
>> feature owner knows what layers are involved and should be
>> responsible to CC
>> relevant MGs in both BZ & thread.
> 
> mailing group is something nobody can manage.

why?, we do not have many layers in the system, creating:
"engine{core, db, network, storage/gluster}, api, ui, sdk, cli, vdsm, node"
mailing groups will do the trick.

> you can consider a group as all people who are CC to a bug.

CC'ing people manually can't guarantee that all relevant people will
be included in the email (thread).

> 
>>
>>> (or we could create a feature mailing list).
>>
>> ML/MG peer feature is too much i think.
>>
>>>
>>> but i do agree we could use bugzilla for tracking features per
>>> version, if wiki isn't tracking this correctly.
>>
>> +1
>>
>>
>> --
>>
>> Michael Pasternak
>> RedHat, ENG-Virtualization R&D
>>


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From alonbl at redhat.com  Sun Dec 23 09:07:23 2012
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Sun, 23 Dec 2012 04:07:23 -0500 (EST)
Subject: [Engine-devel] [SUGGESTION] Defining a process for the new
	feature discussion/implementation.
In-Reply-To: <50D6A3D3.7010701@redhat.com>
Message-ID: <2069177993.6577063.1356253643361.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Michael Pasternak" <mpastern at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, arch at ovirt.org, "Itamar Heim" <iheim at redhat.com>
> Sent: Sunday, December 23, 2012 8:25:23 AM
> Subject: Re: [Engine-devel] [SUGGESTION] Defining a process for the new feature discussion/implementation.
> 
> On 12/21/2012 01:57 PM, Alon Bar-Lev wrote:
> > 
> > 
> > ----- Original Message -----
> >> From: "Michael Pasternak" <mpastern at redhat.com>
> >> To: "Itamar Heim" <iheim at redhat.com>
> >> Cc: "Alon Bar-Lev" <alonbl at redhat.com>, "engine-devel"
> >> <engine-devel at ovirt.org>, arch at ovirt.org
> >> Sent: Friday, December 21, 2012 12:44:51 PM
> >> Subject: Re: [Engine-devel] [SUGGESTION] Defining a process for
> >> the new feature discussion/implementation.
> >>
> >> On 12/21/2012 12:15 AM, Itamar Heim wrote:
> >>> On 12/21/2012 12:12 AM, Alon Bar-Lev wrote:
> >>>>
> >>>>
> >>>> ----- Original Message -----
> >>>>> From: "Itamar Heim" <iheim at redhat.com>
> >>>>> To: "Michael Pasternak" <mpastern at redhat.com>
> >>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> >>>>> Sent: Thursday, December 20, 2012 11:42:37 PM
> >>>>> Subject: Re: [Engine-devel] [SUGGESTION] Defining a process for
> >>>>> the new feature discussion/implementation.
> >>>>>
> >>>>> On 12/19/2012 03:08 PM, Michael Pasternak wrote:
> >>>>>>
> >>>>>> Hi All,
> >>>>>>
> >>>>>> In many cases OSS maintainers not always can be in the loop of
> >>>>>> different threads what may
> >>>>>> cause them missing important decisions being taken,
> >>>>>>
> >>>>>> As result later on during reviews of the patches they're not
> >>>>>> accepting (already implemented)
> >>>>>> features, what is causing not once for feature to be
> >>>>>> re-designed
> >>>>>> and/or delayed, what is wrong
> >>>>>> from the development cycle PoV.
> >>>>>>
> >>>>>> Therefore I'd like to suggest establishing dev-rules for the
> >>>>>> new
> >>>>>> feature implementation,
> >>>>>> what will make entire process much more easer for all of us:
> >>>>>>
> >>>>>> 1. discuss new feature on the mailing list
> >>>>>> (requirements/constraints/etc.)
> >>>>>> 2. summarise feature details in feature-doc
> >>>>>> 3. send feature-doc to review to:
> >>>>>>      3.1 ML (engine-devel)
> >>>>>>      3.2 MG (mailing group of maintainers of the relevant
> >>>>>>      layers)
> >>>>>> 4. after feature-doc is accepted,
> >>>>>>      4.1 implement the feature
> >>>>>>      4.2 send it to gerrit for review to:
> >>>>>>          4.2.1 lead maintainer/s (they will review/delegate
> >>>>>>          it)
> >>>>>>
> >>>>>>
> >>>>>> NOTE 3.2, 4.2.1 will require defining MGs such as:
> >>>>>>         - engine-devel-core
> >>>>>>         - engine-devel-ui
> >>>>>>         - engine-devel-api
> >>>>>>         - engine-devel-sdk
> >>>>>>         - engine-devel-cli
> >>>>>>         - engine-devel-vdsm ...
> >>>>>>
> >>>>>>
> >>>>>> Thoughts?
> >>>>>>
> >>>>>
> >>>>> i thought this is what we have the arch mailing list for, since
> >>>>> any
> >>>>> feature is going to cut through multiple layers/components,
> >>>>> unless
> >>>>> they
> >>>>> are very specific, they should be sent to arch, and all
> >>>>> maintainers
> >>>>> should follow arch.
> >>>>
> >>>> What is missing is upstream bugzilla.
> >>>>
> >>>> A feature, after initiate stage should be represented with a
> >>>> bug.
> >>>> The bug should be assigned to the right designated milestone.
> >>>> All document references (including versions) should be attached
> >>>> or
> >>>> referred by the bug.
> >>>> Dependency between features can be established using bug
> >>>> dependencies.
> >>>> Status can be acquired from buzilla at any time, progress
> >>>> reports
> >>>> should be input into bugzilla.
> >>>> Contact details for the feature can be acquired too, relevant
> >>>> and
> >>>> interested parties can be CCed explicitly.
> >>>> I guess I can add more benefits.
> >>>>
> >>>> Mailing list is good for idea initiation, but not for lifecycle
> >>>> management, nor for people to join at implementation phase and
> >>>> understand why, how and when.
> >>>>
> >>>> Having upstream bugzilla will also help us plan ahead, and
> >>>> manage
> >>>> the break the project into smaller components, to assign core
> >>>> developers for each.
> >>>
> >>> it still won't help tracking all relevant maintainers from rest
> >>> api, ui, engine, vdsm saw the bug. we have multiple components.
> >>> arch is mostly to cover cross component issues, such as features.
> >>
> >> this is why i'm suggesting creating mailing-groups peer component,
> >> feature owner knows what layers are involved and should be
> >> responsible to CC
> >> relevant MGs in both BZ & thread.
> > 
> > mailing group is something nobody can manage.
> 
> why?, we do not have many layers in the system, creating:
> "engine{core, db, network, storage/gluster}, api, ui, sdk, cli, vdsm,
> node"
> mailing groups will do the trick.

Because in open source you don't know who is actually out there.
This is very different from proprietary.
Also, features can be cross component / cross products / cross projects.

You can have default CC in bugzilla for the people you do know, but you must enable other people to subscribe.

> 
> > you can consider a group as all people who are CC to a bug.
> 
> CC'ing people manually can't guarantee that all relevant people will
> be included in the email (thread).
> 
> > 
> >>
> >>> (or we could create a feature mailing list).
> >>
> >> ML/MG peer feature is too much i think.
> >>
> >>>
> >>> but i do agree we could use bugzilla for tracking features per
> >>> version, if wiki isn't tracking this correctly.
> >>
> >> +1
> >>
> >>
> >> --
> >>
> >> Michael Pasternak
> >> RedHat, ENG-Virtualization R&D
> >>
> 
> 
> --
> 
> Michael Pasternak
> RedHat, ENG-Virtualization R&D
> 


From mpastern at redhat.com  Sun Dec 23 09:28:13 2012
From: mpastern at redhat.com (Michael Pasternak)
Date: Sun, 23 Dec 2012 11:28:13 +0200
Subject: [Engine-devel] [SUGGESTION] Defining a process for the new feature
	discussion/implementation.
In-Reply-To: <2069177993.6577063.1356253643361.JavaMail.root@redhat.com>
References: <2069177993.6577063.1356253643361.JavaMail.root@redhat.com>
Message-ID: <50D6CEAD.5020600@redhat.com>

On 12/23/2012 11:07 AM, Alon Bar-Lev wrote:
> 
> 
> ----- Original Message -----
>> From: "Michael Pasternak" <mpastern at redhat.com>
>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>> Cc: "engine-devel" <engine-devel at ovirt.org>, arch at ovirt.org, "Itamar Heim" <iheim at redhat.com>
>> Sent: Sunday, December 23, 2012 8:25:23 AM
>> Subject: Re: [Engine-devel] [SUGGESTION] Defining a process for the new feature discussion/implementation.
>>
>> On 12/21/2012 01:57 PM, Alon Bar-Lev wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Michael Pasternak" <mpastern at redhat.com>
>>>> To: "Itamar Heim" <iheim at redhat.com>
>>>> Cc: "Alon Bar-Lev" <alonbl at redhat.com>, "engine-devel"
>>>> <engine-devel at ovirt.org>, arch at ovirt.org
>>>> Sent: Friday, December 21, 2012 12:44:51 PM
>>>> Subject: Re: [Engine-devel] [SUGGESTION] Defining a process for
>>>> the new feature discussion/implementation.
>>>>
>>>> On 12/21/2012 12:15 AM, Itamar Heim wrote:
>>>>> On 12/21/2012 12:12 AM, Alon Bar-Lev wrote:
>>>>>>
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Itamar Heim" <iheim at redhat.com>
>>>>>>> To: "Michael Pasternak" <mpastern at redhat.com>
>>>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>>>>>>> Sent: Thursday, December 20, 2012 11:42:37 PM
>>>>>>> Subject: Re: [Engine-devel] [SUGGESTION] Defining a process for
>>>>>>> the new feature discussion/implementation.
>>>>>>>
>>>>>>> On 12/19/2012 03:08 PM, Michael Pasternak wrote:
>>>>>>>>
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>> In many cases OSS maintainers not always can be in the loop of
>>>>>>>> different threads what may
>>>>>>>> cause them missing important decisions being taken,
>>>>>>>>
>>>>>>>> As result later on during reviews of the patches they're not
>>>>>>>> accepting (already implemented)
>>>>>>>> features, what is causing not once for feature to be
>>>>>>>> re-designed
>>>>>>>> and/or delayed, what is wrong
>>>>>>>> from the development cycle PoV.
>>>>>>>>
>>>>>>>> Therefore I'd like to suggest establishing dev-rules for the
>>>>>>>> new
>>>>>>>> feature implementation,
>>>>>>>> what will make entire process much more easer for all of us:
>>>>>>>>
>>>>>>>> 1. discuss new feature on the mailing list
>>>>>>>> (requirements/constraints/etc.)
>>>>>>>> 2. summarise feature details in feature-doc
>>>>>>>> 3. send feature-doc to review to:
>>>>>>>>      3.1 ML (engine-devel)
>>>>>>>>      3.2 MG (mailing group of maintainers of the relevant
>>>>>>>>      layers)
>>>>>>>> 4. after feature-doc is accepted,
>>>>>>>>      4.1 implement the feature
>>>>>>>>      4.2 send it to gerrit for review to:
>>>>>>>>          4.2.1 lead maintainer/s (they will review/delegate
>>>>>>>>          it)
>>>>>>>>
>>>>>>>>
>>>>>>>> NOTE 3.2, 4.2.1 will require defining MGs such as:
>>>>>>>>         - engine-devel-core
>>>>>>>>         - engine-devel-ui
>>>>>>>>         - engine-devel-api
>>>>>>>>         - engine-devel-sdk
>>>>>>>>         - engine-devel-cli
>>>>>>>>         - engine-devel-vdsm ...
>>>>>>>>
>>>>>>>>
>>>>>>>> Thoughts?
>>>>>>>>
>>>>>>>
>>>>>>> i thought this is what we have the arch mailing list for, since
>>>>>>> any
>>>>>>> feature is going to cut through multiple layers/components,
>>>>>>> unless
>>>>>>> they
>>>>>>> are very specific, they should be sent to arch, and all
>>>>>>> maintainers
>>>>>>> should follow arch.
>>>>>>
>>>>>> What is missing is upstream bugzilla.
>>>>>>
>>>>>> A feature, after initiate stage should be represented with a
>>>>>> bug.
>>>>>> The bug should be assigned to the right designated milestone.
>>>>>> All document references (including versions) should be attached
>>>>>> or
>>>>>> referred by the bug.
>>>>>> Dependency between features can be established using bug
>>>>>> dependencies.
>>>>>> Status can be acquired from buzilla at any time, progress
>>>>>> reports
>>>>>> should be input into bugzilla.
>>>>>> Contact details for the feature can be acquired too, relevant
>>>>>> and
>>>>>> interested parties can be CCed explicitly.
>>>>>> I guess I can add more benefits.
>>>>>>
>>>>>> Mailing list is good for idea initiation, but not for lifecycle
>>>>>> management, nor for people to join at implementation phase and
>>>>>> understand why, how and when.
>>>>>>
>>>>>> Having upstream bugzilla will also help us plan ahead, and
>>>>>> manage
>>>>>> the break the project into smaller components, to assign core
>>>>>> developers for each.
>>>>>
>>>>> it still won't help tracking all relevant maintainers from rest
>>>>> api, ui, engine, vdsm saw the bug. we have multiple components.
>>>>> arch is mostly to cover cross component issues, such as features.
>>>>
>>>> this is why i'm suggesting creating mailing-groups peer component,
>>>> feature owner knows what layers are involved and should be
>>>> responsible to CC
>>>> relevant MGs in both BZ & thread.
>>>
>>> mailing group is something nobody can manage.
>>
>> why?, we do not have many layers in the system, creating:
>> "engine{core, db, network, storage/gluster}, api, ui, sdk, cli, vdsm,
>> node"
>> mailing groups will do the trick.
> 
> Because in open source you don't know who is actually out there.

this is not about of including everyone in mailing-group, but maintainers,
and you always know who maintainers are.

> This is very different from proprietary.
> Also, features can be cross component / cross products / cross projects.

the one who implementing the feature knows what layers he is touching,
and can trigger relevant mailing-groups (this way feature owner does not
have to be aware of actual layer/s maintainers)

> 
> You can have default CC in bugzilla for the people you do know, but you must enable other people to subscribe.

i'm not talking about bagzila, but the standard process of introducing new
feature, - e.g discussion cannot take place in the bugzila (it's a tool to summarise the feature, etc.),
but i'd like to male sure all relevant maintainers get involved in feature design/discussion
before it get written and not only when they have to review the code, and mailing-groups is a
right tool for that in my view.

> 
>>
>>> you can consider a group as all people who are CC to a bug.
>>
>> CC'ing people manually can't guarantee that all relevant people will
>> be included in the email (thread).
>>
>>>
>>>>
>>>>> (or we could create a feature mailing list).
>>>>
>>>> ML/MG peer feature is too much i think.
>>>>
>>>>>
>>>>> but i do agree we could use bugzilla for tracking features per
>>>>> version, if wiki isn't tracking this correctly.
>>>>
>>>> +1
>>>>
>>>>
>>>> --
>>>>
>>>> Michael Pasternak
>>>> RedHat, ENG-Virtualization R&D
>>>>
>>
>>
>> --
>>
>> Michael Pasternak
>> RedHat, ENG-Virtualization R&D
>>


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From iheim at redhat.com  Sun Dec 23 09:35:40 2012
From: iheim at redhat.com (Itamar Heim)
Date: Sun, 23 Dec 2012 11:35:40 +0200
Subject: [Engine-devel] [SUGGESTION] Defining a process for the new feature
	discussion/implementation.
In-Reply-To: <50D6CEAD.5020600@redhat.com>
References: <2069177993.6577063.1356253643361.JavaMail.root@redhat.com>
	<50D6CEAD.5020600@redhat.com>
Message-ID: <50D6D06C.6020003@redhat.com>

On 12/23/2012 11:28 AM, Michael Pasternak wrote:
> On 12/23/2012 11:07 AM, Alon Bar-Lev wrote:
>>
>>
>> ----- Original Message -----
>>> From: "Michael Pasternak" <mpastern at redhat.com>
>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>>> Cc: "engine-devel" <engine-devel at ovirt.org>, arch at ovirt.org, "Itamar Heim" <iheim at redhat.com>
>>> Sent: Sunday, December 23, 2012 8:25:23 AM
>>> Subject: Re: [Engine-devel] [SUGGESTION] Defining a process for the new feature discussion/implementation.
>>>
>>> On 12/21/2012 01:57 PM, Alon Bar-Lev wrote:
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Michael Pasternak" <mpastern at redhat.com>
>>>>> To: "Itamar Heim" <iheim at redhat.com>
>>>>> Cc: "Alon Bar-Lev" <alonbl at redhat.com>, "engine-devel"
>>>>> <engine-devel at ovirt.org>, arch at ovirt.org
>>>>> Sent: Friday, December 21, 2012 12:44:51 PM
>>>>> Subject: Re: [Engine-devel] [SUGGESTION] Defining a process for
>>>>> the new feature discussion/implementation.
>>>>>
>>>>> On 12/21/2012 12:15 AM, Itamar Heim wrote:
>>>>>> On 12/21/2012 12:12 AM, Alon Bar-Lev wrote:
>>>>>>>
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>>> From: "Itamar Heim" <iheim at redhat.com>
>>>>>>>> To: "Michael Pasternak" <mpastern at redhat.com>
>>>>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>>>>>>>> Sent: Thursday, December 20, 2012 11:42:37 PM
>>>>>>>> Subject: Re: [Engine-devel] [SUGGESTION] Defining a process for
>>>>>>>> the new feature discussion/implementation.
>>>>>>>>
>>>>>>>> On 12/19/2012 03:08 PM, Michael Pasternak wrote:
>>>>>>>>>
>>>>>>>>> Hi All,
>>>>>>>>>
>>>>>>>>> In many cases OSS maintainers not always can be in the loop of
>>>>>>>>> different threads what may
>>>>>>>>> cause them missing important decisions being taken,
>>>>>>>>>
>>>>>>>>> As result later on during reviews of the patches they're not
>>>>>>>>> accepting (already implemented)
>>>>>>>>> features, what is causing not once for feature to be
>>>>>>>>> re-designed
>>>>>>>>> and/or delayed, what is wrong
>>>>>>>>> from the development cycle PoV.
>>>>>>>>>
>>>>>>>>> Therefore I'd like to suggest establishing dev-rules for the
>>>>>>>>> new
>>>>>>>>> feature implementation,
>>>>>>>>> what will make entire process much more easer for all of us:
>>>>>>>>>
>>>>>>>>> 1. discuss new feature on the mailing list
>>>>>>>>> (requirements/constraints/etc.)
>>>>>>>>> 2. summarise feature details in feature-doc
>>>>>>>>> 3. send feature-doc to review to:
>>>>>>>>>       3.1 ML (engine-devel)
>>>>>>>>>       3.2 MG (mailing group of maintainers of the relevant
>>>>>>>>>       layers)
>>>>>>>>> 4. after feature-doc is accepted,
>>>>>>>>>       4.1 implement the feature
>>>>>>>>>       4.2 send it to gerrit for review to:
>>>>>>>>>           4.2.1 lead maintainer/s (they will review/delegate
>>>>>>>>>           it)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> NOTE 3.2, 4.2.1 will require defining MGs such as:
>>>>>>>>>          - engine-devel-core
>>>>>>>>>          - engine-devel-ui
>>>>>>>>>          - engine-devel-api
>>>>>>>>>          - engine-devel-sdk
>>>>>>>>>          - engine-devel-cli
>>>>>>>>>          - engine-devel-vdsm ...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thoughts?
>>>>>>>>>
>>>>>>>>
>>>>>>>> i thought this is what we have the arch mailing list for, since
>>>>>>>> any
>>>>>>>> feature is going to cut through multiple layers/components,
>>>>>>>> unless
>>>>>>>> they
>>>>>>>> are very specific, they should be sent to arch, and all
>>>>>>>> maintainers
>>>>>>>> should follow arch.
>>>>>>>
>>>>>>> What is missing is upstream bugzilla.
>>>>>>>
>>>>>>> A feature, after initiate stage should be represented with a
>>>>>>> bug.
>>>>>>> The bug should be assigned to the right designated milestone.
>>>>>>> All document references (including versions) should be attached
>>>>>>> or
>>>>>>> referred by the bug.
>>>>>>> Dependency between features can be established using bug
>>>>>>> dependencies.
>>>>>>> Status can be acquired from buzilla at any time, progress
>>>>>>> reports
>>>>>>> should be input into bugzilla.
>>>>>>> Contact details for the feature can be acquired too, relevant
>>>>>>> and
>>>>>>> interested parties can be CCed explicitly.
>>>>>>> I guess I can add more benefits.
>>>>>>>
>>>>>>> Mailing list is good for idea initiation, but not for lifecycle
>>>>>>> management, nor for people to join at implementation phase and
>>>>>>> understand why, how and when.
>>>>>>>
>>>>>>> Having upstream bugzilla will also help us plan ahead, and
>>>>>>> manage
>>>>>>> the break the project into smaller components, to assign core
>>>>>>> developers for each.
>>>>>>
>>>>>> it still won't help tracking all relevant maintainers from rest
>>>>>> api, ui, engine, vdsm saw the bug. we have multiple components.
>>>>>> arch is mostly to cover cross component issues, such as features.
>>>>>
>>>>> this is why i'm suggesting creating mailing-groups peer component,
>>>>> feature owner knows what layers are involved and should be
>>>>> responsible to CC
>>>>> relevant MGs in both BZ & thread.
>>>>
>>>> mailing group is something nobody can manage.
>>>
>>> why?, we do not have many layers in the system, creating:
>>> "engine{core, db, network, storage/gluster}, api, ui, sdk, cli, vdsm,
>>> node"
>>> mailing groups will do the trick.
>>
>> Because in open source you don't know who is actually out there.
>
> this is not about of including everyone in mailing-group, but maintainers,
> and you always know who maintainers are.
>
>> This is very different from proprietary.
>> Also, features can be cross component / cross products / cross projects.
>
> the one who implementing the feature knows what layers he is touching,
> and can trigger relevant mailing-groups (this way feature owner does not
> have to be aware of actual layer/s maintainers)
>
>>
>> You can have default CC in bugzilla for the people you do know, but you must enable other people to subscribe.
>
> i'm not talking about bagzila, but the standard process of introducing new
> feature, - e.g discussion cannot take place in the bugzila (it's a tool to summarise the feature, etc.),
> but i'd like to male sure all relevant maintainers get involved in feature design/discussion
> before it get written and not only when they have to review the code, and mailing-groups is a
> right tool for that in my view.

i really expect all maintainers to follow the arch mailing list for this.

>
>>
>>>
>>>> you can consider a group as all people who are CC to a bug.
>>>
>>> CC'ing people manually can't guarantee that all relevant people will
>>> be included in the email (thread).
>>>
>>>>
>>>>>
>>>>>> (or we could create a feature mailing list).
>>>>>
>>>>> ML/MG peer feature is too much i think.
>>>>>
>>>>>>
>>>>>> but i do agree we could use bugzilla for tracking features per
>>>>>> version, if wiki isn't tracking this correctly.
>>>>>
>>>>> +1
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Michael Pasternak
>>>>> RedHat, ENG-Virtualization R&D
>>>>>
>>>
>>>
>>> --
>>>
>>> Michael Pasternak
>>> RedHat, ENG-Virtualization R&D
>>>
>
>




From alonbl at redhat.com  Sun Dec 23 09:39:09 2012
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Sun, 23 Dec 2012 04:39:09 -0500 (EST)
Subject: [Engine-devel] [SUGGESTION] Defining a process for the new
	feature discussion/implementation.
In-Reply-To: <50D6CEAD.5020600@redhat.com>
Message-ID: <530587269.6577245.1356255549940.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Michael Pasternak" <mpastern at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, arch at ovirt.org, "Itamar Heim" <iheim at redhat.com>
> Sent: Sunday, December 23, 2012 11:28:13 AM
> Subject: Re: [Engine-devel] [SUGGESTION] Defining a process for the new feature discussion/implementation.
> 
> On 12/23/2012 11:07 AM, Alon Bar-Lev wrote:
> > 
> > 
> > ----- Original Message -----
> >> From: "Michael Pasternak" <mpastern at redhat.com>
> >> To: "Alon Bar-Lev" <alonbl at redhat.com>
> >> Cc: "engine-devel" <engine-devel at ovirt.org>, arch at ovirt.org,
> >> "Itamar Heim" <iheim at redhat.com>
> >> Sent: Sunday, December 23, 2012 8:25:23 AM
> >> Subject: Re: [Engine-devel] [SUGGESTION] Defining a process for
> >> the new feature discussion/implementation.
> >>
> >> On 12/21/2012 01:57 PM, Alon Bar-Lev wrote:
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Michael Pasternak" <mpastern at redhat.com>
> >>>> To: "Itamar Heim" <iheim at redhat.com>
> >>>> Cc: "Alon Bar-Lev" <alonbl at redhat.com>, "engine-devel"
> >>>> <engine-devel at ovirt.org>, arch at ovirt.org
> >>>> Sent: Friday, December 21, 2012 12:44:51 PM
> >>>> Subject: Re: [Engine-devel] [SUGGESTION] Defining a process for
> >>>> the new feature discussion/implementation.
> >>>>
> >>>> On 12/21/2012 12:15 AM, Itamar Heim wrote:
> >>>>> On 12/21/2012 12:12 AM, Alon Bar-Lev wrote:
> >>>>>>
> >>>>>>
> >>>>>> ----- Original Message -----
> >>>>>>> From: "Itamar Heim" <iheim at redhat.com>
> >>>>>>> To: "Michael Pasternak" <mpastern at redhat.com>
> >>>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> >>>>>>> Sent: Thursday, December 20, 2012 11:42:37 PM
> >>>>>>> Subject: Re: [Engine-devel] [SUGGESTION] Defining a process
> >>>>>>> for
> >>>>>>> the new feature discussion/implementation.
> >>>>>>>
> >>>>>>> On 12/19/2012 03:08 PM, Michael Pasternak wrote:
> >>>>>>>>
> >>>>>>>> Hi All,
> >>>>>>>>
> >>>>>>>> In many cases OSS maintainers not always can be in the loop
> >>>>>>>> of
> >>>>>>>> different threads what may
> >>>>>>>> cause them missing important decisions being taken,
> >>>>>>>>
> >>>>>>>> As result later on during reviews of the patches they're not
> >>>>>>>> accepting (already implemented)
> >>>>>>>> features, what is causing not once for feature to be
> >>>>>>>> re-designed
> >>>>>>>> and/or delayed, what is wrong
> >>>>>>>> from the development cycle PoV.
> >>>>>>>>
> >>>>>>>> Therefore I'd like to suggest establishing dev-rules for the
> >>>>>>>> new
> >>>>>>>> feature implementation,
> >>>>>>>> what will make entire process much more easer for all of us:
> >>>>>>>>
> >>>>>>>> 1. discuss new feature on the mailing list
> >>>>>>>> (requirements/constraints/etc.)
> >>>>>>>> 2. summarise feature details in feature-doc
> >>>>>>>> 3. send feature-doc to review to:
> >>>>>>>>      3.1 ML (engine-devel)
> >>>>>>>>      3.2 MG (mailing group of maintainers of the relevant
> >>>>>>>>      layers)
> >>>>>>>> 4. after feature-doc is accepted,
> >>>>>>>>      4.1 implement the feature
> >>>>>>>>      4.2 send it to gerrit for review to:
> >>>>>>>>          4.2.1 lead maintainer/s (they will review/delegate
> >>>>>>>>          it)
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> NOTE 3.2, 4.2.1 will require defining MGs such as:
> >>>>>>>>         - engine-devel-core
> >>>>>>>>         - engine-devel-ui
> >>>>>>>>         - engine-devel-api
> >>>>>>>>         - engine-devel-sdk
> >>>>>>>>         - engine-devel-cli
> >>>>>>>>         - engine-devel-vdsm ...
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Thoughts?
> >>>>>>>>
> >>>>>>>
> >>>>>>> i thought this is what we have the arch mailing list for,
> >>>>>>> since
> >>>>>>> any
> >>>>>>> feature is going to cut through multiple layers/components,
> >>>>>>> unless
> >>>>>>> they
> >>>>>>> are very specific, they should be sent to arch, and all
> >>>>>>> maintainers
> >>>>>>> should follow arch.
> >>>>>>
> >>>>>> What is missing is upstream bugzilla.
> >>>>>>
> >>>>>> A feature, after initiate stage should be represented with a
> >>>>>> bug.
> >>>>>> The bug should be assigned to the right designated milestone.
> >>>>>> All document references (including versions) should be
> >>>>>> attached
> >>>>>> or
> >>>>>> referred by the bug.
> >>>>>> Dependency between features can be established using bug
> >>>>>> dependencies.
> >>>>>> Status can be acquired from buzilla at any time, progress
> >>>>>> reports
> >>>>>> should be input into bugzilla.
> >>>>>> Contact details for the feature can be acquired too, relevant
> >>>>>> and
> >>>>>> interested parties can be CCed explicitly.
> >>>>>> I guess I can add more benefits.
> >>>>>>
> >>>>>> Mailing list is good for idea initiation, but not for
> >>>>>> lifecycle
> >>>>>> management, nor for people to join at implementation phase and
> >>>>>> understand why, how and when.
> >>>>>>
> >>>>>> Having upstream bugzilla will also help us plan ahead, and
> >>>>>> manage
> >>>>>> the break the project into smaller components, to assign core
> >>>>>> developers for each.
> >>>>>
> >>>>> it still won't help tracking all relevant maintainers from rest
> >>>>> api, ui, engine, vdsm saw the bug. we have multiple components.
> >>>>> arch is mostly to cover cross component issues, such as
> >>>>> features.
> >>>>
> >>>> this is why i'm suggesting creating mailing-groups peer
> >>>> component,
> >>>> feature owner knows what layers are involved and should be
> >>>> responsible to CC
> >>>> relevant MGs in both BZ & thread.
> >>>
> >>> mailing group is something nobody can manage.
> >>
> >> why?, we do not have many layers in the system, creating:
> >> "engine{core, db, network, storage/gluster}, api, ui, sdk, cli,
> >> vdsm,
> >> node"
> >> mailing groups will do the trick.
> > 
> > Because in open source you don't know who is actually out there.
> 
> this is not about of including everyone in mailing-group, but
> maintainers,
> and you always know who maintainers are.

I am sorry, but this is not "open" discussion.
You *DO NOT* know who is interested, there can be other people that are highly valuable for a discussion and you are going to loose them.

Maintainer is not someone who is more important the contributer, he just has commit access.

> 
> > This is very different from proprietary.
> > Also, features can be cross component / cross products / cross
> > projects.
> 
> the one who implementing the feature knows what layers he is
> touching,
> and can trigger relevant mailing-groups (this way feature owner does
> not
> have to be aware of actual layer/s maintainers)

Again, you lose one of the most important open source benefit, allowing everyone to participate and contribute.

If you like, a message subject convention will be more productive, "maintainer" may set trigger for a specific prefix, and there can be a documentation of this convention for features and other uses.

All discussions should be made in public, this is burden but also opportunity.

> > 
> > You can have default CC in bugzilla for the people you do know, but
> > you must enable other people to subscribe.
> 
> i'm not talking about bagzila, but the standard process of
> introducing new
> feature, - e.g discussion cannot take place in the bugzila (it's a
> tool to summarise the feature, etc.),
> but i'd like to male sure all relevant maintainers get involved in
> feature design/discussion
> before it get written and not only when they have to review the code,
> and mailing-groups is a
> right tool for that in my view.
> 
> > 
> >>
> >>> you can consider a group as all people who are CC to a bug.
> >>
> >> CC'ing people manually can't guarantee that all relevant people
> >> will
> >> be included in the email (thread).
> >>
> >>>
> >>>>
> >>>>> (or we could create a feature mailing list).
> >>>>
> >>>> ML/MG peer feature is too much i think.
> >>>>
> >>>>>
> >>>>> but i do agree we could use bugzilla for tracking features per
> >>>>> version, if wiki isn't tracking this correctly.
> >>>>
> >>>> +1
> >>>>
> >>>>
> >>>> --
> >>>>
> >>>> Michael Pasternak
> >>>> RedHat, ENG-Virtualization R&D
> >>>>
> >>
> >>
> >> --
> >>
> >> Michael Pasternak
> >> RedHat, ENG-Virtualization R&D
> >>
> 
> 
> --
> 
> Michael Pasternak
> RedHat, ENG-Virtualization R&D
> 


From mpastern at redhat.com  Sun Dec 23 09:52:56 2012
From: mpastern at redhat.com (Michael Pasternak)
Date: Sun, 23 Dec 2012 11:52:56 +0200
Subject: [Engine-devel] [SUGGESTION] Defining a process for the new feature
	discussion/implementation.
In-Reply-To: <50D6D06C.6020003@redhat.com>
References: <2069177993.6577063.1356253643361.JavaMail.root@redhat.com>
	<50D6CEAD.5020600@redhat.com> <50D6D06C.6020003@redhat.com>
Message-ID: <50D6D478.7050006@redhat.com>

On 12/23/2012 11:35 AM, Itamar Heim wrote:
> On 12/23/2012 11:28 AM, Michael Pasternak wrote:
>> On 12/23/2012 11:07 AM, Alon Bar-Lev wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Michael Pasternak" <mpastern at redhat.com>
>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>>>> Cc: "engine-devel" <engine-devel at ovirt.org>, arch at ovirt.org, "Itamar Heim" <iheim at redhat.com>
>>>> Sent: Sunday, December 23, 2012 8:25:23 AM
>>>> Subject: Re: [Engine-devel] [SUGGESTION] Defining a process for the new feature discussion/implementation.
>>>>
>>>> On 12/21/2012 01:57 PM, Alon Bar-Lev wrote:
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Michael Pasternak" <mpastern at redhat.com>
>>>>>> To: "Itamar Heim" <iheim at redhat.com>
>>>>>> Cc: "Alon Bar-Lev" <alonbl at redhat.com>, "engine-devel"
>>>>>> <engine-devel at ovirt.org>, arch at ovirt.org
>>>>>> Sent: Friday, December 21, 2012 12:44:51 PM
>>>>>> Subject: Re: [Engine-devel] [SUGGESTION] Defining a process for
>>>>>> the new feature discussion/implementation.
>>>>>>
>>>>>> On 12/21/2012 12:15 AM, Itamar Heim wrote:
>>>>>>> On 12/21/2012 12:12 AM, Alon Bar-Lev wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>>> From: "Itamar Heim" <iheim at redhat.com>
>>>>>>>>> To: "Michael Pasternak" <mpastern at redhat.com>
>>>>>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>>>>>>>>> Sent: Thursday, December 20, 2012 11:42:37 PM
>>>>>>>>> Subject: Re: [Engine-devel] [SUGGESTION] Defining a process for
>>>>>>>>> the new feature discussion/implementation.
>>>>>>>>>
>>>>>>>>> On 12/19/2012 03:08 PM, Michael Pasternak wrote:
>>>>>>>>>>
>>>>>>>>>> Hi All,
>>>>>>>>>>
>>>>>>>>>> In many cases OSS maintainers not always can be in the loop of
>>>>>>>>>> different threads what may
>>>>>>>>>> cause them missing important decisions being taken,
>>>>>>>>>>
>>>>>>>>>> As result later on during reviews of the patches they're not
>>>>>>>>>> accepting (already implemented)
>>>>>>>>>> features, what is causing not once for feature to be
>>>>>>>>>> re-designed
>>>>>>>>>> and/or delayed, what is wrong
>>>>>>>>>> from the development cycle PoV.
>>>>>>>>>>
>>>>>>>>>> Therefore I'd like to suggest establishing dev-rules for the
>>>>>>>>>> new
>>>>>>>>>> feature implementation,
>>>>>>>>>> what will make entire process much more easer for all of us:
>>>>>>>>>>
>>>>>>>>>> 1. discuss new feature on the mailing list
>>>>>>>>>> (requirements/constraints/etc.)
>>>>>>>>>> 2. summarise feature details in feature-doc
>>>>>>>>>> 3. send feature-doc to review to:
>>>>>>>>>>       3.1 ML (engine-devel)
>>>>>>>>>>       3.2 MG (mailing group of maintainers of the relevant
>>>>>>>>>>       layers)
>>>>>>>>>> 4. after feature-doc is accepted,
>>>>>>>>>>       4.1 implement the feature
>>>>>>>>>>       4.2 send it to gerrit for review to:
>>>>>>>>>>           4.2.1 lead maintainer/s (they will review/delegate
>>>>>>>>>>           it)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> NOTE 3.2, 4.2.1 will require defining MGs such as:
>>>>>>>>>>          - engine-devel-core
>>>>>>>>>>          - engine-devel-ui
>>>>>>>>>>          - engine-devel-api
>>>>>>>>>>          - engine-devel-sdk
>>>>>>>>>>          - engine-devel-cli
>>>>>>>>>>          - engine-devel-vdsm ...
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thoughts?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> i thought this is what we have the arch mailing list for, since
>>>>>>>>> any
>>>>>>>>> feature is going to cut through multiple layers/components,
>>>>>>>>> unless
>>>>>>>>> they
>>>>>>>>> are very specific, they should be sent to arch, and all
>>>>>>>>> maintainers
>>>>>>>>> should follow arch.
>>>>>>>>
>>>>>>>> What is missing is upstream bugzilla.
>>>>>>>>
>>>>>>>> A feature, after initiate stage should be represented with a
>>>>>>>> bug.
>>>>>>>> The bug should be assigned to the right designated milestone.
>>>>>>>> All document references (including versions) should be attached
>>>>>>>> or
>>>>>>>> referred by the bug.
>>>>>>>> Dependency between features can be established using bug
>>>>>>>> dependencies.
>>>>>>>> Status can be acquired from buzilla at any time, progress
>>>>>>>> reports
>>>>>>>> should be input into bugzilla.
>>>>>>>> Contact details for the feature can be acquired too, relevant
>>>>>>>> and
>>>>>>>> interested parties can be CCed explicitly.
>>>>>>>> I guess I can add more benefits.
>>>>>>>>
>>>>>>>> Mailing list is good for idea initiation, but not for lifecycle
>>>>>>>> management, nor for people to join at implementation phase and
>>>>>>>> understand why, how and when.
>>>>>>>>
>>>>>>>> Having upstream bugzilla will also help us plan ahead, and
>>>>>>>> manage
>>>>>>>> the break the project into smaller components, to assign core
>>>>>>>> developers for each.
>>>>>>>
>>>>>>> it still won't help tracking all relevant maintainers from rest
>>>>>>> api, ui, engine, vdsm saw the bug. we have multiple components.
>>>>>>> arch is mostly to cover cross component issues, such as features.
>>>>>>
>>>>>> this is why i'm suggesting creating mailing-groups peer component,
>>>>>> feature owner knows what layers are involved and should be
>>>>>> responsible to CC
>>>>>> relevant MGs in both BZ & thread.
>>>>>
>>>>> mailing group is something nobody can manage.
>>>>
>>>> why?, we do not have many layers in the system, creating:
>>>> "engine{core, db, network, storage/gluster}, api, ui, sdk, cli, vdsm,
>>>> node"
>>>> mailing groups will do the trick.
>>>
>>> Because in open source you don't know who is actually out there.
>>
>> this is not about of including everyone in mailing-group, but maintainers,
>> and you always know who maintainers are.
>>
>>> This is very different from proprietary.
>>> Also, features can be cross component / cross products / cross projects.
>>
>> the one who implementing the feature knows what layers he is touching,
>> and can trigger relevant mailing-groups (this way feature owner does not
>> have to be aware of actual layer/s maintainers)
>>
>>>
>>> You can have default CC in bugzilla for the people you do know, but you must enable other people to subscribe.
>>
>> i'm not talking about bagzila, but the standard process of introducing new
>> feature, - e.g discussion cannot take place in the bugzila (it's a tool to summarise the feature, etc.),
>> but i'd like to male sure all relevant maintainers get involved in feature design/discussion
>> before it get written and not only when they have to review the code, and mailing-groups is a
>> right tool for that in my view.
> 
> i really expect all maintainers to follow the arch mailing list for this.

Itamar,

i think it's not feasible, people has a lot of constraints and can easily miss stuff,
getting personal notifications is much more practical and can dramatically reduce
redesign of the features during review processes, what is quite painful for the contributors,

i think this way it will be much more easer to follow feature discussions, and i'm sure
it won't cause maintainers to stop following mailing lists,

just entire process will become much more productive for both sides.

> 
>>
>>>
>>>>
>>>>> you can consider a group as all people who are CC to a bug.
>>>>
>>>> CC'ing people manually can't guarantee that all relevant people will
>>>> be included in the email (thread).
>>>>
>>>>>
>>>>>>
>>>>>>> (or we could create a feature mailing list).
>>>>>>
>>>>>> ML/MG peer feature is too much i think.
>>>>>>
>>>>>>>
>>>>>>> but i do agree we could use bugzilla for tracking features per
>>>>>>> version, if wiki isn't tracking this correctly.
>>>>>>
>>>>>> +1
>>>>>>
>>>>>>
>>>>>> -- 
>>>>>>
>>>>>> Michael Pasternak
>>>>>> RedHat, ENG-Virtualization R&D
>>>>>>
>>>>
>>>>
>>>> -- 
>>>>
>>>> Michael Pasternak
>>>> RedHat, ENG-Virtualization R&D
>>>>
>>
>>
> 
> 


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From mpastern at redhat.com  Sun Dec 23 10:01:25 2012
From: mpastern at redhat.com (Michael Pasternak)
Date: Sun, 23 Dec 2012 12:01:25 +0200
Subject: [Engine-devel] [SUGGESTION] Defining a process for the new feature
	discussion/implementation.
In-Reply-To: <530587269.6577245.1356255549940.JavaMail.root@redhat.com>
References: <530587269.6577245.1356255549940.JavaMail.root@redhat.com>
Message-ID: <50D6D675.6050808@redhat.com>

On 12/23/2012 11:39 AM, Alon Bar-Lev wrote:
> 
> 
> ----- Original Message -----
>> From: "Michael Pasternak" <mpastern at redhat.com>
>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>> Cc: "engine-devel" <engine-devel at ovirt.org>, arch at ovirt.org, "Itamar Heim" <iheim at redhat.com>
>> Sent: Sunday, December 23, 2012 11:28:13 AM
>> Subject: Re: [Engine-devel] [SUGGESTION] Defining a process for the new feature discussion/implementation.
>>
>> On 12/23/2012 11:07 AM, Alon Bar-Lev wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Michael Pasternak" <mpastern at redhat.com>
>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>>>> Cc: "engine-devel" <engine-devel at ovirt.org>, arch at ovirt.org,
>>>> "Itamar Heim" <iheim at redhat.com>
>>>> Sent: Sunday, December 23, 2012 8:25:23 AM
>>>> Subject: Re: [Engine-devel] [SUGGESTION] Defining a process for
>>>> the new feature discussion/implementation.
>>>>
>>>> On 12/21/2012 01:57 PM, Alon Bar-Lev wrote:
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Michael Pasternak" <mpastern at redhat.com>
>>>>>> To: "Itamar Heim" <iheim at redhat.com>
>>>>>> Cc: "Alon Bar-Lev" <alonbl at redhat.com>, "engine-devel"
>>>>>> <engine-devel at ovirt.org>, arch at ovirt.org
>>>>>> Sent: Friday, December 21, 2012 12:44:51 PM
>>>>>> Subject: Re: [Engine-devel] [SUGGESTION] Defining a process for
>>>>>> the new feature discussion/implementation.
>>>>>>
>>>>>> On 12/21/2012 12:15 AM, Itamar Heim wrote:
>>>>>>> On 12/21/2012 12:12 AM, Alon Bar-Lev wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>>> From: "Itamar Heim" <iheim at redhat.com>
>>>>>>>>> To: "Michael Pasternak" <mpastern at redhat.com>
>>>>>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>>>>>>>>> Sent: Thursday, December 20, 2012 11:42:37 PM
>>>>>>>>> Subject: Re: [Engine-devel] [SUGGESTION] Defining a process
>>>>>>>>> for
>>>>>>>>> the new feature discussion/implementation.
>>>>>>>>>
>>>>>>>>> On 12/19/2012 03:08 PM, Michael Pasternak wrote:
>>>>>>>>>>
>>>>>>>>>> Hi All,
>>>>>>>>>>
>>>>>>>>>> In many cases OSS maintainers not always can be in the loop
>>>>>>>>>> of
>>>>>>>>>> different threads what may
>>>>>>>>>> cause them missing important decisions being taken,
>>>>>>>>>>
>>>>>>>>>> As result later on during reviews of the patches they're not
>>>>>>>>>> accepting (already implemented)
>>>>>>>>>> features, what is causing not once for feature to be
>>>>>>>>>> re-designed
>>>>>>>>>> and/or delayed, what is wrong
>>>>>>>>>> from the development cycle PoV.
>>>>>>>>>>
>>>>>>>>>> Therefore I'd like to suggest establishing dev-rules for the
>>>>>>>>>> new
>>>>>>>>>> feature implementation,
>>>>>>>>>> what will make entire process much more easer for all of us:
>>>>>>>>>>
>>>>>>>>>> 1. discuss new feature on the mailing list
>>>>>>>>>> (requirements/constraints/etc.)
>>>>>>>>>> 2. summarise feature details in feature-doc
>>>>>>>>>> 3. send feature-doc to review to:
>>>>>>>>>>      3.1 ML (engine-devel)
>>>>>>>>>>      3.2 MG (mailing group of maintainers of the relevant
>>>>>>>>>>      layers)
>>>>>>>>>> 4. after feature-doc is accepted,
>>>>>>>>>>      4.1 implement the feature
>>>>>>>>>>      4.2 send it to gerrit for review to:
>>>>>>>>>>          4.2.1 lead maintainer/s (they will review/delegate
>>>>>>>>>>          it)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> NOTE 3.2, 4.2.1 will require defining MGs such as:
>>>>>>>>>>         - engine-devel-core
>>>>>>>>>>         - engine-devel-ui
>>>>>>>>>>         - engine-devel-api
>>>>>>>>>>         - engine-devel-sdk
>>>>>>>>>>         - engine-devel-cli
>>>>>>>>>>         - engine-devel-vdsm ...
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thoughts?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> i thought this is what we have the arch mailing list for,
>>>>>>>>> since
>>>>>>>>> any
>>>>>>>>> feature is going to cut through multiple layers/components,
>>>>>>>>> unless
>>>>>>>>> they
>>>>>>>>> are very specific, they should be sent to arch, and all
>>>>>>>>> maintainers
>>>>>>>>> should follow arch.
>>>>>>>>
>>>>>>>> What is missing is upstream bugzilla.
>>>>>>>>
>>>>>>>> A feature, after initiate stage should be represented with a
>>>>>>>> bug.
>>>>>>>> The bug should be assigned to the right designated milestone.
>>>>>>>> All document references (including versions) should be
>>>>>>>> attached
>>>>>>>> or
>>>>>>>> referred by the bug.
>>>>>>>> Dependency between features can be established using bug
>>>>>>>> dependencies.
>>>>>>>> Status can be acquired from buzilla at any time, progress
>>>>>>>> reports
>>>>>>>> should be input into bugzilla.
>>>>>>>> Contact details for the feature can be acquired too, relevant
>>>>>>>> and
>>>>>>>> interested parties can be CCed explicitly.
>>>>>>>> I guess I can add more benefits.
>>>>>>>>
>>>>>>>> Mailing list is good for idea initiation, but not for
>>>>>>>> lifecycle
>>>>>>>> management, nor for people to join at implementation phase and
>>>>>>>> understand why, how and when.
>>>>>>>>
>>>>>>>> Having upstream bugzilla will also help us plan ahead, and
>>>>>>>> manage
>>>>>>>> the break the project into smaller components, to assign core
>>>>>>>> developers for each.
>>>>>>>
>>>>>>> it still won't help tracking all relevant maintainers from rest
>>>>>>> api, ui, engine, vdsm saw the bug. we have multiple components.
>>>>>>> arch is mostly to cover cross component issues, such as
>>>>>>> features.
>>>>>>
>>>>>> this is why i'm suggesting creating mailing-groups peer
>>>>>> component,
>>>>>> feature owner knows what layers are involved and should be
>>>>>> responsible to CC
>>>>>> relevant MGs in both BZ & thread.
>>>>>
>>>>> mailing group is something nobody can manage.
>>>>
>>>> why?, we do not have many layers in the system, creating:
>>>> "engine{core, db, network, storage/gluster}, api, ui, sdk, cli,
>>>> vdsm,
>>>> node"
>>>> mailing groups will do the trick.
>>>
>>> Because in open source you don't know who is actually out there.
>>
>> this is not about of including everyone in mailing-group, but
>> maintainers,
>> and you always know who maintainers are.
> 
> I am sorry, but this is not "open" discussion.
> You *DO NOT* know who is interested, there can be other people that are highly valuable for a discussion and you are going to loose them.

how possible you will loose them? adding mailing-group/s of maintainers does *not* mean
excluding the mailing list itself ...

anyone that is interested in discussion can still follow it.

> 
> Maintainer is not someone who is more important the contributer, he just has commit access.

i do agree about maintainers not being "more important" than contributor, but for sure maintainers have more
experience with the projects and planned stuff, so they can drive features to the right direction ...

> 
>>
>>> This is very different from proprietary.
>>> Also, features can be cross component / cross products / cross
>>> projects.
>>
>> the one who implementing the feature knows what layers he is
>> touching,
>> and can trigger relevant mailing-groups (this way feature owner does
>> not
>> have to be aware of actual layer/s maintainers)
> 
> Again, you lose one of the most important open source benefit, allowing everyone to participate and contribute.
> 
> If you like, a message subject convention will be more productive, "maintainer" may set trigger for a specific prefix, and there can be a documentation of this convention for features and other uses.
> 
> All discussions should be made in public, this is burden but also opportunity.

Alon,

i think you missed the point, read my answer ^ above, + entire thread was started,
to make sure maintainers explicitly got involved in to design of the features and
not changing it when the code is written (what for sure will make contributors frustrated)

> 
>>>
>>> You can have default CC in bugzilla for the people you do know, but
>>> you must enable other people to subscribe.
>>
>> i'm not talking about bagzila, but the standard process of
>> introducing new
>> feature, - e.g discussion cannot take place in the bugzila (it's a
>> tool to summarise the feature, etc.),
>> but i'd like to male sure all relevant maintainers get involved in
>> feature design/discussion
>> before it get written and not only when they have to review the code,
>> and mailing-groups is a
>> right tool for that in my view.
>>
>>>
>>>>
>>>>> you can consider a group as all people who are CC to a bug.
>>>>
>>>> CC'ing people manually can't guarantee that all relevant people
>>>> will
>>>> be included in the email (thread).
>>>>
>>>>>
>>>>>>
>>>>>>> (or we could create a feature mailing list).
>>>>>>
>>>>>> ML/MG peer feature is too much i think.
>>>>>>
>>>>>>>
>>>>>>> but i do agree we could use bugzilla for tracking features per
>>>>>>> version, if wiki isn't tracking this correctly.
>>>>>>
>>>>>> +1
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Michael Pasternak
>>>>>> RedHat, ENG-Virtualization R&D
>>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Michael Pasternak
>>>> RedHat, ENG-Virtualization R&D
>>>>
>>
>>
>> --
>>
>> Michael Pasternak
>> RedHat, ENG-Virtualization R&D
>>


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From alonbl at redhat.com  Sun Dec 23 10:16:54 2012
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Sun, 23 Dec 2012 05:16:54 -0500 (EST)
Subject: [Engine-devel] [SUGGESTION] Defining a process for the new
	feature discussion/implementation.
In-Reply-To: <50D6D675.6050808@redhat.com>
Message-ID: <1935203280.6577398.1356257814058.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Michael Pasternak" <mpastern at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, arch at ovirt.org, "Itamar Heim" <iheim at redhat.com>
> Sent: Sunday, December 23, 2012 12:01:25 PM
> Subject: Re: [Engine-devel] [SUGGESTION] Defining a process for the new feature discussion/implementation.
> 
> On 12/23/2012 11:39 AM, Alon Bar-Lev wrote:
> > 
> > 
> > ----- Original Message -----
> >> From: "Michael Pasternak" <mpastern at redhat.com>
> >> To: "Alon Bar-Lev" <alonbl at redhat.com>
> >> Cc: "engine-devel" <engine-devel at ovirt.org>, arch at ovirt.org,
> >> "Itamar Heim" <iheim at redhat.com>
> >> Sent: Sunday, December 23, 2012 11:28:13 AM
> >> Subject: Re: [Engine-devel] [SUGGESTION] Defining a process for
> >> the new feature discussion/implementation.
> >>
> >> On 12/23/2012 11:07 AM, Alon Bar-Lev wrote:
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Michael Pasternak" <mpastern at redhat.com>
> >>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
> >>>> Cc: "engine-devel" <engine-devel at ovirt.org>, arch at ovirt.org,
> >>>> "Itamar Heim" <iheim at redhat.com>
> >>>> Sent: Sunday, December 23, 2012 8:25:23 AM
> >>>> Subject: Re: [Engine-devel] [SUGGESTION] Defining a process for
> >>>> the new feature discussion/implementation.
> >>>>
> >>>> On 12/21/2012 01:57 PM, Alon Bar-Lev wrote:
> >>>>>
> >>>>>
> >>>>> ----- Original Message -----
> >>>>>> From: "Michael Pasternak" <mpastern at redhat.com>
> >>>>>> To: "Itamar Heim" <iheim at redhat.com>
> >>>>>> Cc: "Alon Bar-Lev" <alonbl at redhat.com>, "engine-devel"
> >>>>>> <engine-devel at ovirt.org>, arch at ovirt.org
> >>>>>> Sent: Friday, December 21, 2012 12:44:51 PM
> >>>>>> Subject: Re: [Engine-devel] [SUGGESTION] Defining a process
> >>>>>> for
> >>>>>> the new feature discussion/implementation.
> >>>>>>
> >>>>>> On 12/21/2012 12:15 AM, Itamar Heim wrote:
> >>>>>>> On 12/21/2012 12:12 AM, Alon Bar-Lev wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> ----- Original Message -----
> >>>>>>>>> From: "Itamar Heim" <iheim at redhat.com>
> >>>>>>>>> To: "Michael Pasternak" <mpastern at redhat.com>
> >>>>>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> >>>>>>>>> Sent: Thursday, December 20, 2012 11:42:37 PM
> >>>>>>>>> Subject: Re: [Engine-devel] [SUGGESTION] Defining a process
> >>>>>>>>> for
> >>>>>>>>> the new feature discussion/implementation.
> >>>>>>>>>
> >>>>>>>>> On 12/19/2012 03:08 PM, Michael Pasternak wrote:
> >>>>>>>>>>
> >>>>>>>>>> Hi All,
> >>>>>>>>>>
> >>>>>>>>>> In many cases OSS maintainers not always can be in the
> >>>>>>>>>> loop
> >>>>>>>>>> of
> >>>>>>>>>> different threads what may
> >>>>>>>>>> cause them missing important decisions being taken,
> >>>>>>>>>>
> >>>>>>>>>> As result later on during reviews of the patches they're
> >>>>>>>>>> not
> >>>>>>>>>> accepting (already implemented)
> >>>>>>>>>> features, what is causing not once for feature to be
> >>>>>>>>>> re-designed
> >>>>>>>>>> and/or delayed, what is wrong
> >>>>>>>>>> from the development cycle PoV.
> >>>>>>>>>>
> >>>>>>>>>> Therefore I'd like to suggest establishing dev-rules for
> >>>>>>>>>> the
> >>>>>>>>>> new
> >>>>>>>>>> feature implementation,
> >>>>>>>>>> what will make entire process much more easer for all of
> >>>>>>>>>> us:
> >>>>>>>>>>
> >>>>>>>>>> 1. discuss new feature on the mailing list
> >>>>>>>>>> (requirements/constraints/etc.)
> >>>>>>>>>> 2. summarise feature details in feature-doc
> >>>>>>>>>> 3. send feature-doc to review to:
> >>>>>>>>>>      3.1 ML (engine-devel)
> >>>>>>>>>>      3.2 MG (mailing group of maintainers of the relevant
> >>>>>>>>>>      layers)
> >>>>>>>>>> 4. after feature-doc is accepted,
> >>>>>>>>>>      4.1 implement the feature
> >>>>>>>>>>      4.2 send it to gerrit for review to:
> >>>>>>>>>>          4.2.1 lead maintainer/s (they will
> >>>>>>>>>>          review/delegate
> >>>>>>>>>>          it)
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> NOTE 3.2, 4.2.1 will require defining MGs such as:
> >>>>>>>>>>         - engine-devel-core
> >>>>>>>>>>         - engine-devel-ui
> >>>>>>>>>>         - engine-devel-api
> >>>>>>>>>>         - engine-devel-sdk
> >>>>>>>>>>         - engine-devel-cli
> >>>>>>>>>>         - engine-devel-vdsm ...
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Thoughts?
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> i thought this is what we have the arch mailing list for,
> >>>>>>>>> since
> >>>>>>>>> any
> >>>>>>>>> feature is going to cut through multiple layers/components,
> >>>>>>>>> unless
> >>>>>>>>> they
> >>>>>>>>> are very specific, they should be sent to arch, and all
> >>>>>>>>> maintainers
> >>>>>>>>> should follow arch.
> >>>>>>>>
> >>>>>>>> What is missing is upstream bugzilla.
> >>>>>>>>
> >>>>>>>> A feature, after initiate stage should be represented with a
> >>>>>>>> bug.
> >>>>>>>> The bug should be assigned to the right designated
> >>>>>>>> milestone.
> >>>>>>>> All document references (including versions) should be
> >>>>>>>> attached
> >>>>>>>> or
> >>>>>>>> referred by the bug.
> >>>>>>>> Dependency between features can be established using bug
> >>>>>>>> dependencies.
> >>>>>>>> Status can be acquired from buzilla at any time, progress
> >>>>>>>> reports
> >>>>>>>> should be input into bugzilla.
> >>>>>>>> Contact details for the feature can be acquired too,
> >>>>>>>> relevant
> >>>>>>>> and
> >>>>>>>> interested parties can be CCed explicitly.
> >>>>>>>> I guess I can add more benefits.
> >>>>>>>>
> >>>>>>>> Mailing list is good for idea initiation, but not for
> >>>>>>>> lifecycle
> >>>>>>>> management, nor for people to join at implementation phase
> >>>>>>>> and
> >>>>>>>> understand why, how and when.
> >>>>>>>>
> >>>>>>>> Having upstream bugzilla will also help us plan ahead, and
> >>>>>>>> manage
> >>>>>>>> the break the project into smaller components, to assign
> >>>>>>>> core
> >>>>>>>> developers for each.
> >>>>>>>
> >>>>>>> it still won't help tracking all relevant maintainers from
> >>>>>>> rest
> >>>>>>> api, ui, engine, vdsm saw the bug. we have multiple
> >>>>>>> components.
> >>>>>>> arch is mostly to cover cross component issues, such as
> >>>>>>> features.
> >>>>>>
> >>>>>> this is why i'm suggesting creating mailing-groups peer
> >>>>>> component,
> >>>>>> feature owner knows what layers are involved and should be
> >>>>>> responsible to CC
> >>>>>> relevant MGs in both BZ & thread.
> >>>>>
> >>>>> mailing group is something nobody can manage.
> >>>>
> >>>> why?, we do not have many layers in the system, creating:
> >>>> "engine{core, db, network, storage/gluster}, api, ui, sdk, cli,
> >>>> vdsm,
> >>>> node"
> >>>> mailing groups will do the trick.
> >>>
> >>> Because in open source you don't know who is actually out there.
> >>
> >> this is not about of including everyone in mailing-group, but
> >> maintainers,
> >> and you always know who maintainers are.
> > 
> > I am sorry, but this is not "open" discussion.
> > You *DO NOT* know who is interested, there can be other people that
> > are highly valuable for a discussion and you are going to loose
> > them.
> 
> how possible you will loose them? adding mailing-group/s of
> maintainers does *not* mean
> excluding the mailing list itself ...

So why do you need the group?
I don't understand... maybe provide another projects that works this way?

> 
> anyone that is interested in discussion can still follow it.
> 
> > 
> > Maintainer is not someone who is more important the contributer, he
> > just has commit access.
> 
> i do agree about maintainers not being "more important" than
> contributor, but for sure maintainers have more
> experience with the projects and planned stuff, so they can drive
> features to the right direction ...
> 
> > 
> >>
> >>> This is very different from proprietary.
> >>> Also, features can be cross component / cross products / cross
> >>> projects.
> >>
> >> the one who implementing the feature knows what layers he is
> >> touching,
> >> and can trigger relevant mailing-groups (this way feature owner
> >> does
> >> not
> >> have to be aware of actual layer/s maintainers)
> > 
> > Again, you lose one of the most important open source benefit,
> > allowing everyone to participate and contribute.
> > 
> > If you like, a message subject convention will be more productive,
> > "maintainer" may set trigger for a specific prefix, and there can
> > be a documentation of this convention for features and other uses.
> > 
> > All discussions should be made in public, this is burden but also
> > opportunity.
> 
> Alon,
> 
> i think you missed the point, read my answer ^ above, + entire thread
> was started,
> to make sure maintainers explicitly got involved in to design of the
> features and
> not changing it when the code is written (what for sure will make
> contributors frustrated)
> 
> > 
> >>>
> >>> You can have default CC in bugzilla for the people you do know,
> >>> but
> >>> you must enable other people to subscribe.
> >>
> >> i'm not talking about bagzila, but the standard process of
> >> introducing new
> >> feature, - e.g discussion cannot take place in the bugzila (it's a
> >> tool to summarise the feature, etc.),
> >> but i'd like to male sure all relevant maintainers get involved in
> >> feature design/discussion
> >> before it get written and not only when they have to review the
> >> code,
> >> and mailing-groups is a
> >> right tool for that in my view.
> >>
> >>>
> >>>>
> >>>>> you can consider a group as all people who are CC to a bug.
> >>>>
> >>>> CC'ing people manually can't guarantee that all relevant people
> >>>> will
> >>>> be included in the email (thread).
> >>>>
> >>>>>
> >>>>>>
> >>>>>>> (or we could create a feature mailing list).
> >>>>>>
> >>>>>> ML/MG peer feature is too much i think.
> >>>>>>
> >>>>>>>
> >>>>>>> but i do agree we could use bugzilla for tracking features
> >>>>>>> per
> >>>>>>> version, if wiki isn't tracking this correctly.
> >>>>>>
> >>>>>> +1
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>>
> >>>>>> Michael Pasternak
> >>>>>> RedHat, ENG-Virtualization R&D
> >>>>>>
> >>>>
> >>>>
> >>>> --
> >>>>
> >>>> Michael Pasternak
> >>>> RedHat, ENG-Virtualization R&D
> >>>>
> >>
> >>
> >> --
> >>
> >> Michael Pasternak
> >> RedHat, ENG-Virtualization R&D
> >>
> 
> 
> --
> 
> Michael Pasternak
> RedHat, ENG-Virtualization R&D
> 


From mpastern at redhat.com  Sun Dec 23 10:27:25 2012
From: mpastern at redhat.com (Michael Pasternak)
Date: Sun, 23 Dec 2012 12:27:25 +0200
Subject: [Engine-devel] [SUGGESTION] Defining a process for the new feature
	discussion/implementation.
In-Reply-To: <1935203280.6577398.1356257814058.JavaMail.root@redhat.com>
References: <1935203280.6577398.1356257814058.JavaMail.root@redhat.com>
Message-ID: <50D6DC8D.6020901@redhat.com>

On 12/23/2012 12:16 PM, Alon Bar-Lev wrote:
> 
> ----- Original Message -----
>> > From: "Michael Pasternak" <mpastern at redhat.com>
>> > To: "Alon Bar-Lev" <alonbl at redhat.com>
>> > Cc: "engine-devel" <engine-devel at ovirt.org>, arch at ovirt.org, "Itamar Heim" <iheim at redhat.com>
>> > Sent: Sunday, December 23, 2012 12:01:25 PM
>> > Subject: Re: [Engine-devel] [SUGGESTION] Defining a process for the new feature discussion/implementation.
>> > 
>> > On 12/23/2012 11:39 AM, Alon Bar-Lev wrote:
>>> > > 
>>> > > 
>>> > > ----- Original Message -----
>>>> > >> From: "Michael Pasternak" <mpastern at redhat.com>
>>>> > >> To: "Alon Bar-Lev" <alonbl at redhat.com>
>>>> > >> Cc: "engine-devel" <engine-devel at ovirt.org>, arch at ovirt.org,
>>>> > >> "Itamar Heim" <iheim at redhat.com>
>>>> > >> Sent: Sunday, December 23, 2012 11:28:13 AM
>>>> > >> Subject: Re: [Engine-devel] [SUGGESTION] Defining a process for
>>>> > >> the new feature discussion/implementation.
>>>> > >>
>>>> > >> On 12/23/2012 11:07 AM, Alon Bar-Lev wrote:
>>>>> > >>>
>>>>> > >>>
>>>>> > >>> ----- Original Message -----
>>>>>> > >>>> From: "Michael Pasternak" <mpastern at redhat.com>
>>>>>> > >>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>>>>>> > >>>> Cc: "engine-devel" <engine-devel at ovirt.org>, arch at ovirt.org,
>>>>>> > >>>> "Itamar Heim" <iheim at redhat.com>
>>>>>> > >>>> Sent: Sunday, December 23, 2012 8:25:23 AM
>>>>>> > >>>> Subject: Re: [Engine-devel] [SUGGESTION] Defining a process for
>>>>>> > >>>> the new feature discussion/implementation.
>>>>>> > >>>>
>>>>>> > >>>> On 12/21/2012 01:57 PM, Alon Bar-Lev wrote:
>>>>>>> > >>>>>
>>>>>>> > >>>>>
>>>>>>> > >>>>> ----- Original Message -----
>>>>>>>> > >>>>>> From: "Michael Pasternak" <mpastern at redhat.com>
>>>>>>>> > >>>>>> To: "Itamar Heim" <iheim at redhat.com>
>>>>>>>> > >>>>>> Cc: "Alon Bar-Lev" <alonbl at redhat.com>, "engine-devel"
>>>>>>>> > >>>>>> <engine-devel at ovirt.org>, arch at ovirt.org
>>>>>>>> > >>>>>> Sent: Friday, December 21, 2012 12:44:51 PM
>>>>>>>> > >>>>>> Subject: Re: [Engine-devel] [SUGGESTION] Defining a process
>>>>>>>> > >>>>>> for
>>>>>>>> > >>>>>> the new feature discussion/implementation.
>>>>>>>> > >>>>>>
>>>>>>>> > >>>>>> On 12/21/2012 12:15 AM, Itamar Heim wrote:
>>>>>>>>> > >>>>>>> On 12/21/2012 12:12 AM, Alon Bar-Lev wrote:
>>>>>>>>>> > >>>>>>>>
>>>>>>>>>> > >>>>>>>>
>>>>>>>>>> > >>>>>>>> ----- Original Message -----
>>>>>>>>>>> > >>>>>>>>> From: "Itamar Heim" <iheim at redhat.com>
>>>>>>>>>>> > >>>>>>>>> To: "Michael Pasternak" <mpastern at redhat.com>
>>>>>>>>>>> > >>>>>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>>>>>>>>>>> > >>>>>>>>> Sent: Thursday, December 20, 2012 11:42:37 PM
>>>>>>>>>>> > >>>>>>>>> Subject: Re: [Engine-devel] [SUGGESTION] Defining a process
>>>>>>>>>>> > >>>>>>>>> for
>>>>>>>>>>> > >>>>>>>>> the new feature discussion/implementation.
>>>>>>>>>>> > >>>>>>>>>
>>>>>>>>>>> > >>>>>>>>> On 12/19/2012 03:08 PM, Michael Pasternak wrote:
>>>>>>>>>>>> > >>>>>>>>>>
>>>>>>>>>>>> > >>>>>>>>>> Hi All,
>>>>>>>>>>>> > >>>>>>>>>>
>>>>>>>>>>>> > >>>>>>>>>> In many cases OSS maintainers not always can be in the
>>>>>>>>>>>> > >>>>>>>>>> loop
>>>>>>>>>>>> > >>>>>>>>>> of
>>>>>>>>>>>> > >>>>>>>>>> different threads what may
>>>>>>>>>>>> > >>>>>>>>>> cause them missing important decisions being taken,
>>>>>>>>>>>> > >>>>>>>>>>
>>>>>>>>>>>> > >>>>>>>>>> As result later on during reviews of the patches they're
>>>>>>>>>>>> > >>>>>>>>>> not
>>>>>>>>>>>> > >>>>>>>>>> accepting (already implemented)
>>>>>>>>>>>> > >>>>>>>>>> features, what is causing not once for feature to be
>>>>>>>>>>>> > >>>>>>>>>> re-designed
>>>>>>>>>>>> > >>>>>>>>>> and/or delayed, what is wrong
>>>>>>>>>>>> > >>>>>>>>>> from the development cycle PoV.
>>>>>>>>>>>> > >>>>>>>>>>
>>>>>>>>>>>> > >>>>>>>>>> Therefore I'd like to suggest establishing dev-rules for
>>>>>>>>>>>> > >>>>>>>>>> the
>>>>>>>>>>>> > >>>>>>>>>> new
>>>>>>>>>>>> > >>>>>>>>>> feature implementation,
>>>>>>>>>>>> > >>>>>>>>>> what will make entire process much more easer for all of
>>>>>>>>>>>> > >>>>>>>>>> us:
>>>>>>>>>>>> > >>>>>>>>>>
>>>>>>>>>>>> > >>>>>>>>>> 1. discuss new feature on the mailing list
>>>>>>>>>>>> > >>>>>>>>>> (requirements/constraints/etc.)
>>>>>>>>>>>> > >>>>>>>>>> 2. summarise feature details in feature-doc
>>>>>>>>>>>> > >>>>>>>>>> 3. send feature-doc to review to:
>>>>>>>>>>>> > >>>>>>>>>>      3.1 ML (engine-devel)
>>>>>>>>>>>> > >>>>>>>>>>      3.2 MG (mailing group of maintainers of the relevant
>>>>>>>>>>>> > >>>>>>>>>>      layers)
>>>>>>>>>>>> > >>>>>>>>>> 4. after feature-doc is accepted,
>>>>>>>>>>>> > >>>>>>>>>>      4.1 implement the feature
>>>>>>>>>>>> > >>>>>>>>>>      4.2 send it to gerrit for review to:
>>>>>>>>>>>> > >>>>>>>>>>          4.2.1 lead maintainer/s (they will
>>>>>>>>>>>> > >>>>>>>>>>          review/delegate
>>>>>>>>>>>> > >>>>>>>>>>          it)
>>>>>>>>>>>> > >>>>>>>>>>
>>>>>>>>>>>> > >>>>>>>>>>
>>>>>>>>>>>> > >>>>>>>>>> NOTE 3.2, 4.2.1 will require defining MGs such as:
>>>>>>>>>>>> > >>>>>>>>>>         - engine-devel-core
>>>>>>>>>>>> > >>>>>>>>>>         - engine-devel-ui
>>>>>>>>>>>> > >>>>>>>>>>         - engine-devel-api
>>>>>>>>>>>> > >>>>>>>>>>         - engine-devel-sdk
>>>>>>>>>>>> > >>>>>>>>>>         - engine-devel-cli
>>>>>>>>>>>> > >>>>>>>>>>         - engine-devel-vdsm ...
>>>>>>>>>>>> > >>>>>>>>>>
>>>>>>>>>>>> > >>>>>>>>>>
>>>>>>>>>>>> > >>>>>>>>>> Thoughts?
>>>>>>>>>>>> > >>>>>>>>>>
>>>>>>>>>>> > >>>>>>>>>
>>>>>>>>>>> > >>>>>>>>> i thought this is what we have the arch mailing list for,
>>>>>>>>>>> > >>>>>>>>> since
>>>>>>>>>>> > >>>>>>>>> any
>>>>>>>>>>> > >>>>>>>>> feature is going to cut through multiple layers/components,
>>>>>>>>>>> > >>>>>>>>> unless
>>>>>>>>>>> > >>>>>>>>> they
>>>>>>>>>>> > >>>>>>>>> are very specific, they should be sent to arch, and all
>>>>>>>>>>> > >>>>>>>>> maintainers
>>>>>>>>>>> > >>>>>>>>> should follow arch.
>>>>>>>>>> > >>>>>>>>
>>>>>>>>>> > >>>>>>>> What is missing is upstream bugzilla.
>>>>>>>>>> > >>>>>>>>
>>>>>>>>>> > >>>>>>>> A feature, after initiate stage should be represented with a
>>>>>>>>>> > >>>>>>>> bug.
>>>>>>>>>> > >>>>>>>> The bug should be assigned to the right designated
>>>>>>>>>> > >>>>>>>> milestone.
>>>>>>>>>> > >>>>>>>> All document references (including versions) should be
>>>>>>>>>> > >>>>>>>> attached
>>>>>>>>>> > >>>>>>>> or
>>>>>>>>>> > >>>>>>>> referred by the bug.
>>>>>>>>>> > >>>>>>>> Dependency between features can be established using bug
>>>>>>>>>> > >>>>>>>> dependencies.
>>>>>>>>>> > >>>>>>>> Status can be acquired from buzilla at any time, progress
>>>>>>>>>> > >>>>>>>> reports
>>>>>>>>>> > >>>>>>>> should be input into bugzilla.
>>>>>>>>>> > >>>>>>>> Contact details for the feature can be acquired too,
>>>>>>>>>> > >>>>>>>> relevant
>>>>>>>>>> > >>>>>>>> and
>>>>>>>>>> > >>>>>>>> interested parties can be CCed explicitly.
>>>>>>>>>> > >>>>>>>> I guess I can add more benefits.
>>>>>>>>>> > >>>>>>>>
>>>>>>>>>> > >>>>>>>> Mailing list is good for idea initiation, but not for
>>>>>>>>>> > >>>>>>>> lifecycle
>>>>>>>>>> > >>>>>>>> management, nor for people to join at implementation phase
>>>>>>>>>> > >>>>>>>> and
>>>>>>>>>> > >>>>>>>> understand why, how and when.
>>>>>>>>>> > >>>>>>>>
>>>>>>>>>> > >>>>>>>> Having upstream bugzilla will also help us plan ahead, and
>>>>>>>>>> > >>>>>>>> manage
>>>>>>>>>> > >>>>>>>> the break the project into smaller components, to assign
>>>>>>>>>> > >>>>>>>> core
>>>>>>>>>> > >>>>>>>> developers for each.
>>>>>>>>> > >>>>>>>
>>>>>>>>> > >>>>>>> it still won't help tracking all relevant maintainers from
>>>>>>>>> > >>>>>>> rest
>>>>>>>>> > >>>>>>> api, ui, engine, vdsm saw the bug. we have multiple
>>>>>>>>> > >>>>>>> components.
>>>>>>>>> > >>>>>>> arch is mostly to cover cross component issues, such as
>>>>>>>>> > >>>>>>> features.
>>>>>>>> > >>>>>>
>>>>>>>> > >>>>>> this is why i'm suggesting creating mailing-groups peer
>>>>>>>> > >>>>>> component,
>>>>>>>> > >>>>>> feature owner knows what layers are involved and should be
>>>>>>>> > >>>>>> responsible to CC
>>>>>>>> > >>>>>> relevant MGs in both BZ & thread.
>>>>>>> > >>>>>
>>>>>>> > >>>>> mailing group is something nobody can manage.
>>>>>> > >>>>
>>>>>> > >>>> why?, we do not have many layers in the system, creating:
>>>>>> > >>>> "engine{core, db, network, storage/gluster}, api, ui, sdk, cli,
>>>>>> > >>>> vdsm,
>>>>>> > >>>> node"
>>>>>> > >>>> mailing groups will do the trick.
>>>>> > >>>
>>>>> > >>> Because in open source you don't know who is actually out there.
>>>> > >>
>>>> > >> this is not about of including everyone in mailing-group, but
>>>> > >> maintainers,
>>>> > >> and you always know who maintainers are.
>>> > > 
>>> > > I am sorry, but this is not "open" discussion.
>>> > > You *DO NOT* know who is interested, there can be other people that
>>> > > are highly valuable for a discussion and you are going to loose
>>> > > them.
>> > 
>> > how possible you will loose them? adding mailing-group/s of
>> > maintainers does *not* mean
>> > excluding the mailing list itself ...
> So why do you need the group?

please see very first email of this tread, you will see there that suggestion
works like this:

1. discuss new feature on the mailing list (requirements/constraints/etc.)
2. summarise feature details in feature-doc
3. send feature-doc to review to:
   3.1 ML (engine-devel)
   3.2 MG (mailing group of maintainers of the relevant layers)
4. after feature-doc is accepted,
   4.1 implement the feature
   4.2 send it to gerrit for review to:
       4.2.1 lead maintainer/s (they will review/delegate it)

(3.1 answer your concerns from the previous email)

-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From geoffocallaghan at gmail.com  Mon Dec 24 09:22:57 2012
From: geoffocallaghan at gmail.com (Geoff O'Callaghan)
Date: Mon, 24 Dec 2012 20:22:57 +1100
Subject: API documentation
Message-ID: <CACBaits6JPLKxxN6PgSf95zQWpd9mktr4w2PszmeJNg0wUYHxA@mail.gmail.com>

Hi All,

Is there somewhere where all the ovirt (& related components) API
documentation resides? I've had a look and i'm willing to say that i'm
going blind but I couldn't find it.

Any clues?

Tks
Geoff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20121224/0fc1163b/attachment.html>

From dneary at redhat.com  Mon Dec 24 11:21:01 2012
From: dneary at redhat.com (Dave Neary)
Date: Mon, 24 Dec 2012 12:21:01 +0100
Subject: oVirt Workshop - agenda online!
Message-ID: <50D83A9D.7010703@redhat.com>

Hi everyone,

The provisional agenda for the oVirt Workshop in Sunnyvale is now 
online! We have lined up a very attractive schedule, I think, covering 
user case studies, integrator stories, and sessions useful for both 
newcomers to the oVirt project and partners interested in integrating or 
modifying the project: http://www.ovirt.org/NetApp_Workshop_January_2013

A reminder that you can still register for this free workshop, which 
will be held in Sunnyvale, California from January 22-24 2013, at 
http://ovirtnetapp2013.eventbrite.com/ - registration will close on 
January 14th.

Thank you all! And happy holidays for those of you who celebrate Christmas!

Regards,
Dave.

-- 
Dave Neary - Community Action and Impact
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13


From iheim at redhat.com  Mon Dec 24 15:15:06 2012
From: iheim at redhat.com (Itamar Heim)
Date: Mon, 24 Dec 2012 17:15:06 +0200
Subject: API documentation
In-Reply-To: <CACBaits6JPLKxxN6PgSf95zQWpd9mktr4w2PszmeJNg0wUYHxA@mail.gmail.com>
References: <CACBaits6JPLKxxN6PgSf95zQWpd9mktr4w2PszmeJNg0wUYHxA@mail.gmail.com>
Message-ID: <50D8717A.60301@redhat.com>

On 12/24/2012 11:22 AM, Geoff O'Callaghan wrote:
> Hi All,
>
> Is there somewhere where all the ovirt (& related components) API
> documentation resides? I've had a look and i'm willing to say that i'm
> going blind but I couldn't find it.
>
> Any clues?
>
> Tks
> Geoff
>
>
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
>

the rhev documentation is the closest thing:
https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Virtualization/3.1/html-single/Developer_Guide/index.html



From iheim at redhat.com  Mon Dec 24 21:47:56 2012
From: iheim at redhat.com (Itamar Heim)
Date: Mon, 24 Dec 2012 23:47:56 +0200
Subject: KVM on IBM POWER (PPC64) support in vdsm and ovirt
In-Reply-To: <50CA7041.2090802@redhat.com>
References: <504CC616.60501@in.ibm.com> <50839EBA.1080301@redhat.com>
	<509A7B86.4050700@linux.vnet.ibm.com>	<509CA431.8080405@redhat.com>
	<50A1F141.9010500@redhat.com> <50A236E4.1070304@linux.vnet.ibm.com>
	<50A67925.1010704@linux.vnet.ibm.com>
	<50A8CAC9.9090403@redhat.com> <50CA7041.2090802@redhat.com>
Message-ID: <50D8CD8C.8030407@redhat.com>

On 12/14/2012 02:18 AM, Roy Golan wrote:
> On 11/18/2012 01:47 PM, Itamar Heim wrote:
>> On 11/16/2012 07:34 PM, Fernando Granha Jeronimo wrote:
>>> On 11/13/2012 10:02 AM, Paulo de Rezende Pinatti wrote:
>>>> On 11/13/2012 05:05 AM, Itamar Heim wrote:
>>>>> On 11/09/2012 08:35 AM, Itamar Heim wrote:
>>>>>> On 11/07/2012 04:17 PM, Paulo de Rezende Pinatti wrote:
>>>>>>> Hello all,
>>>>>>>
>>>>>>> I have consolidated the ideas for enabling ppc64 in ovirt-engine
>>>>>>> in a
>>>>>>> feature page:
>>>>>>> http://wiki.ovirt.org/wiki/Features/Engine_support_for_PPC64
>>>>>>>
>>>>>>> Suggestions and comments are greatly appreciated.
>>>>>>
>>>>>> iiuc, the most obvious change to mention is addition of an 'arch'
>>>>>> field
>>>>>> to cluster, which would affect the list of supported cpu families,
>>>>>> etc.?
>>>>>> (and to later know to filter all other aspects of entities based on
>>>>>> this
>>>>>> arch field)?
>>>>>>
>>>>>> list of possible arch's would be per cluster compatibility level.
>>>>>> i'd expect default for API of this field to be x86_64 for backward
>>>>>> compatibility, so it is not mandatory.
>>>>>> I'd also prefer this field to be disabled or hidden if there is only
>>>>>> one
>>>>>> option available in it.
>>>>>>
>>>>>> it gets more complicated, as VMs can be moved around between
>>>>>> clusters,
>>>>>> exported/imported, etc.
>>>>>>
>>>>>> you would need to validate a VM isn't moved to a cluster with a
>>>>>> different arch, or imported into a cluster with a different arch as
>>>>>> well.
>>>>>> (probably more like that).
>>>>>>
>>>>>> i assume the config to filter device types per arch like the network
>>>>>> devices is also for console (spice), audio, etc.
>>>>>>
>>>>>> the system already has the concept of filtering per cluster level, so
>>>>>> filtering per cluster level and arch would mean reviewing all
>>>>>> places in
>>>>>> code for that.
>>>>>
>>>>> I'm adding roy/omer/michal as the work on libosinfo (patches in
>>>>> gerrit[1]) seems to make some of these changes not needed (if it is
>>>>> merged).
>>>>> rather just need to extend libosinfo with the information on ppc.
>>>>>
>>>>> for sure worth reviewing both approaches to make sure the chosen
>>>>> solution benefits both and we collaborate on same end goal.
>>>>
>>>> thanks, we will check these patches and possibly change the approach
>>>> to use libosinfo.
>>>>
>>> Hello,
>>>
>>> We have carefully analyzed the engine libosinfo patches and the
>>> libosinfo itself to devise
>>> our conclusion. During this process, we found the following key points:
>>>
>>>    * In order to have a clear notion of supported versions and devices,
>>> we would
>>>      need to populate libosinfo's xmls for qemu and for devices, as well
>>> as implement logic in
>>>      ovirt-engine to process the relationship between them. This would
>>> be basically partially
>>>      reimplement the lib itself. In addition, given that we are not
>>> using the lib but actually processing
>>>      the xmls directly there is no guarantee that their structure will
>>> be preserved in the future,
>>>      which in the mid/long term may lead to code changes in the engine
>>> to adapt to it.
>>
>> I thought that is what roy's patches are doing?
>> i agree about the concern if the xml is changing.
> all of your concerns have been brought up. please have a look at the
> discussion around how to integrate with libosinfo
> http://lists.ovirt.org/pipermail/arch/2012-September/000924.html
> any comments about it would be appreciated.

I didn't see there anything on using a different config file/options per 
cluster level?

>>
>>>    * Even if libosinfo had all the information we needed in the xmls, we
>>> would still need to validate
>>>      or filter values according to ovirt-engine's rules. For instance,
>>> if the list of network devices
>>>      for PowerKVM in libosinfo had 5 elements and the engine only
>>> intended to support/expose 2 specific models,
>>>      (for a given version for example) it has to be aware of these two
>>> models, meaning that even using libosinfo
>>>      we still need something in engine to validate them (which
>>> reinforces Itamar's filter suggestion).
>>
>> good point - Roy, how would cluster level compatibility for features
>> would work in your libosinfo approach?
> I'd have to keep a set of devices per arch as libosinfo doesn't cover that.

or add it to libosinfo?

>>
>>
>>>
>>> The primary concern of libosinfo patches is focused on virtual machine
>>> parameters validation based on OS.
>>> With regard to Power KVM support it doesn't address other areas like
>>> hypervisor/cluster validation logic.
>>
>> well, this could just be since it wasn't populated for a non x86_64
>> arch. would it make sense for you to discuss ppc support for libosinfo
>> regardless?
>>
>>> Based on that and the exposed in the previous items, an approach that
>>> seems to make sense if the libosinfo patches
>>> are merged is to keep the focus of libosinfo usage as it is and for the
>>> other areas to use the suggested in the
>>> PowerKVM feature page
>>> (http://wiki.ovirt.org/wiki/Features/Engine_support_for_PPC64). This
>>> would benefit both and
>>> converge to a project's solution.
>>>
>>> Appreciate comments you may have.
>>>
>>> Kind regards,
>>>>>
>>>>> [1] some of the patches are:
>>>>> http://gerrit.ovirt.org/9065
>>>>> http://gerrit.ovirt.org/9063
>>>>> http://gerrit.ovirt.org/9049
>>>>>
>>>>
>>>> _______________________________________________
>>>> Arch mailing list
>>>> Arch at ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/arch
>>>>
>>>
>>> _______________________________________________
>>> Arch mailing list
>>> Arch at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/arch
>>
>>
>




From danken at redhat.com  Tue Dec 25 12:27:22 2012
From: danken at redhat.com (Dan Kenigsberg)
Date: Tue, 25 Dec 2012 14:27:22 +0200
Subject: feature suggestion: initial generation of management network
Message-ID: <20121225122722.GG7274@redhat.com>

Current condition:
==================
The management network, named ovirtmgmt, is created during host
bootstrap. It consists of a bridge device, connected to the network
device that was used to communicate with Engine (nic, bonding or vlan).
It inherits its ip settings from the latter device.

Why Is the Management Network Needed?
=====================================
Understandably, some may ask why do we need to have a management
network - why having a host with IPv4 configured on it is not enough.
The answer is twofold:
1. In oVirt, a network is an abstraction of the resources required for
   connectivity of a host for a specific usage. This is true for the
   management network just as it is for VM network or a display network.
   The network entity is the key for adding/changing nics and IP
   address.
2. In many occasions (such as small setups) the management network is
   used as a VM/display network as well.

Problems in current connectivity:
================================
According to alonbl of ovirt-host-deploy fame, and with no conflict to
my own experience, creating the management network is the most fragile,
error-prone step of bootstrap.

Currently it always creates a bridged network (even if the DC requires a
non-bridged ovirtmgmt), it knows nothing about the defined MTU for
ovirtmgmt, it uses ping to guess on top of which device to build (and
thus requires Vdsm-to-Engine reverse connectivity), and is the sole
remaining user of the addNetwork/vdsm-store-net-conf scripts.

Suggested feature:
==================
Bootstrap would avoid creating a management network. Instead, after
bootstrapping a host, Engine would send a getVdsCaps probe to the
installed host, receiving a complete picture of the network
configuration on the host. Among this picture is the device that holds
the host's management IP address.

Engine would send setupNetwork command to generate ovirtmgmt with
details devised from this picture, and according to the DC definition of
ovirtmgmt.  For example, if Vdsm reports:

- vlan bond4.3000 has the host's IP, configured to use dhcp.
- bond4 is comprises eth2 and eth3
- ovirtmgmt is defined as a VM network with MTU 9000

then Engine sends the likes of:
  setupNetworks(ovirtmgmt: {bridged=True, vlan=3000, iface=bond4,
                bonding=bond4: {eth2,eth3}, MTU=9000)

A call to setSafeNetConfig would wrap the network configuration up.

Currently, the host underegoes a reboot as the last step of bootstrap.
This allows us to verify immediately if the host would be accessible
post-boot using its new network configuration. If we want to maintain
this, Engine would need to send a fenceNode request.

Benefits:
=========
- Simplified bootstrapping
- Simplified ovirt-node registration (similar ovirtmgmt-generation logic
  lies there).
- Host installation ends with an ovirtmgmt network that matches DC
  definition (bridged-ness, mtu, vlan).
- vdsm-to-engine connectivity is not required.

Drawbacks:
==========
- We need to implement new Engine logic for devising ovirtmgmt definition out of
  getVdsCaps output.
- ... your input is welcome here

Missing:
========
A wiki feature page for this new behavior.




From alonbl at redhat.com  Tue Dec 25 14:27:00 2012
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Tue, 25 Dec 2012 09:27:00 -0500 (EST)
Subject: feature suggestion: initial generation of management network
In-Reply-To: <20121225122722.GG7274@redhat.com>
Message-ID: <210179126.6639317.1356445620996.JavaMail.root@redhat.com>


<snip>

Of course I would like to see this happening as fast as we can!
No need for duplicate logic, nor the difference between deployment and standard operation.

I also think we can remove the ovirtmgmt concept in time.. as if I understand correctly, we do not actually need a special network for management, it may be treated the same as any other network.

Thanks!
Alon


From simon at redhat.com  Tue Dec 25 14:29:26 2012
From: simon at redhat.com (Simon Grinberg)
Date: Tue, 25 Dec 2012 09:29:26 -0500 (EST)
Subject: feature suggestion: initial generation of management network
In-Reply-To: <20121225122722.GG7274@redhat.com>
Message-ID: <27623755.252.1356445712988.JavaMail.javamailuser@localhost>



----- Original Message -----
> From: "Dan Kenigsberg" <danken at redhat.com>
> To: "arch" <arch at ovirt.org>
> Sent: Tuesday, December 25, 2012 2:27:22 PM
> Subject: feature suggestion: initial generation of management network
> 
> Current condition:
> ==================
> The management network, named ovirtmgmt, is created during host
> bootstrap. It consists of a bridge device, connected to the network
> device that was used to communicate with Engine (nic, bonding or
> vlan).
> It inherits its ip settings from the latter device.
> 
> Why Is the Management Network Needed?
> =====================================
> Understandably, some may ask why do we need to have a management
> network - why having a host with IPv4 configured on it is not enough.
> The answer is twofold:
> 1. In oVirt, a network is an abstraction of the resources required
> for
>    connectivity of a host for a specific usage. This is true for the
>    management network just as it is for VM network or a display
>    network.
>    The network entity is the key for adding/changing nics and IP
>    address.
> 2. In many occasions (such as small setups) the management network is
>    used as a VM/display network as well.
> 
> Problems in current connectivity:
> ================================
> According to alonbl of ovirt-host-deploy fame, and with no conflict
> to
> my own experience, creating the management network is the most
> fragile,
> error-prone step of bootstrap.

+1, 
I've raise that repeatedly in the past, bootstrap should not create the management network but pick up the existing configuration and let the engine override later with it's own configuration if it differs , I'm glad that we finally get to that. 

> 
> Currently it always creates a bridged network (even if the DC
> requires a
> non-bridged ovirtmgmt), it knows nothing about the defined MTU for
> ovirtmgmt, it uses ping to guess on top of which device to build (and
> thus requires Vdsm-to-Engine reverse connectivity), and is the sole
> remaining user of the addNetwork/vdsm-store-net-conf scripts.
> 
> Suggested feature:
> ==================
> Bootstrap would avoid creating a management network. Instead, after
> bootstrapping a host, Engine would send a getVdsCaps probe to the
> installed host, receiving a complete picture of the network
> configuration on the host. Among this picture is the device that
> holds
> the host's management IP address.
> 
> Engine would send setupNetwork command to generate ovirtmgmt with
> details devised from this picture, and according to the DC definition
> of
> ovirtmgmt.  For example, if Vdsm reports:
> 
> - vlan bond4.3000 has the host's IP, configured to use dhcp.
> - bond4 is comprises eth2 and eth3
> - ovirtmgmt is defined as a VM network with MTU 9000
> 
> then Engine sends the likes of:
>   setupNetworks(ovirtmgmt: {bridged=True, vlan=3000, iface=bond4,
>                 bonding=bond4: {eth2,eth3}, MTU=9000)

Just one comment here, 
In order to save time and confusion - if the ovirtmgmt is defined with default values meaning the user did not bother to touch it, let it pick up the VLAN configuration from the first host added in the Data Center. 

Otherwise, you may override the host VLAN and loose connectivity.

This will also solve the situation many users encounter today. 
1. The engine in on a host that actually has VLAN defined 
2. The ovirtmgmt network was not updated in the DC
3. A host, with VLAN already defined is added - everything works fine
4. Any number of hosts are now added, again everything seems to work fine. 

But, now try to use setupNetworks, and you'll find out that you can't do much on the interface that contains the ovirtmgmt since the definition does not match. You can't sync (Since this will remove the VLAN and cause connectivity lose) you can't add more networks on top since it already has non-VLAN network on top according to the DC definition, etc.

On the other hand you can't update the ovirtmgmt definition on the DC since there are clusters in the DC that use the network.

The only workaround not involving DB hack to change the VLAN on the network is to:
1. Create new DC 
2. Do not use the wizard that pops up to create your cluster.
3. Modify the ovirtmgmt network to have VLANs 
4. Now create a cluster and add your hosts.

If you insist on using the default DC and cluster then before adding the first host, create an additional DC and move the Default cluster over there. You may then change the network on the Default cluster and then move the Default cluster back

Both are ugly. And should be solved by the proposal above. 

We do something similar for the Default cluster CPU level, where we set the intial level based on the first host added to the cluster. 

> 
> A call to setSafeNetConfig would wrap the network configuration up.
> 
> Currently, the host underegoes a reboot as the last step of
> bootstrap.
> This allows us to verify immediately if the host would be accessible
> post-boot using its new network configuration. If we want to maintain
> this, Engine would need to send a fenceNode request.
> 
> Benefits:
> =========
> - Simplified bootstrapping
> - Simplified ovirt-node registration (similar ovirtmgmt-generation
> logic lies there).
> - Host installation ends with an ovirtmgmt network that matches DC
>   definition (bridged-ness, mtu, vlan).
> - vdsm-to-engine connectivity is not required.
> 
> Drawbacks:
> ==========
> - We need to implement new Engine logic for devising ovirtmgmt
> definition out of getVdsCaps output.

That is not a drawback - it's just writing code. Drawback as I see it, is within the suggested feature on the final behaviour and code. 

> - ... your input is welcome here
> 
> Missing:
> ========
> A wiki feature page for this new behavior.
> 
> 
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


From simon at redhat.com  Tue Dec 25 14:32:41 2012
From: simon at redhat.com (Simon Grinberg)
Date: Tue, 25 Dec 2012 09:32:41 -0500 (EST)
Subject: feature suggestion: initial generation of management network
In-Reply-To: <210179126.6639317.1356445620996.JavaMail.root@redhat.com>
Message-ID: <13731326.262.1356445905444.JavaMail.javamailuser@localhost>



----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "Dan Kenigsberg" <danken at redhat.com>
> Cc: "arch" <arch at ovirt.org>
> Sent: Tuesday, December 25, 2012 4:27:00 PM
> Subject: Re: feature suggestion: initial generation of management network
> 
> 
> <snip>
> 
> Of course I would like to see this happening as fast as we can!
> No need for duplicate logic, nor the difference between deployment
> and standard operation.
> 
> I also think we can remove the ovirtmgmt concept in time.. as if I
> understand correctly, we do not actually need a special network for
> management, it may be treated the same as any other network.

You'll need that in order to apply SLA and monitor it's usage. Like you've said it's a network and as any other network that has a special functionality you may be required to apply attributes to it.  

> 
> Thanks!
> Alon
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


From acathrow at redhat.com  Wed Dec 26 00:19:44 2012
From: acathrow at redhat.com (Andrew Cathrow)
Date: Tue, 25 Dec 2012 19:19:44 -0500 (EST)
Subject: API documentation
In-Reply-To: <CACBaits6JPLKxxN6PgSf95zQWpd9mktr4w2PszmeJNg0wUYHxA@mail.gmail.com>
Message-ID: <1943043385.58168626.1356481184962.JavaMail.root@redhat.com>

Downstream is here. 
https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Virtualization/3.1/html-single/Developer_Guide/index.html 

----- Original Message -----

> From: "Geoff O'Callaghan" <geoffocallaghan at gmail.com>
> To: arch at ovirt.org
> Sent: Monday, December 24, 2012 4:22:57 AM
> Subject: API documentation

> Hi All,

> Is there somewhere where all the ovirt (& related components) API
> documentation resides? I've had a look and i'm willing to say that
> i'm going blind but I couldn't find it.

> Any clues?

> Tks
> Geoff
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20121225/b2ba665c/attachment.html>

From dougsland at redhat.com  Wed Dec 26 04:18:50 2012
From: dougsland at redhat.com (Douglas Landgraf)
Date: Tue, 25 Dec 2012 23:18:50 -0500
Subject: API documentation
In-Reply-To: <1943043385.58168626.1356481184962.JavaMail.root@redhat.com>
References: <1943043385.58168626.1356481184962.JavaMail.root@redhat.com>
Message-ID: <50DA7AAA.1070403@redhat.com>

Hi,

On 12/25/2012 07:19 PM, Andrew Cathrow wrote:
> Downstream is here.
> https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Virtualization/3.1/html-single/Developer_Guide/index.html
>

There are REST API examples available here as well:
https://github.com/dougsland/ovirt-restapi-scripts/wiki

> ------------------------------------------------------------------------
>
>     *From: *"Geoff O'Callaghan" <geoffocallaghan at gmail.com>
>     *To: *arch at ovirt.org
>     *Sent: *Monday, December 24, 2012 4:22:57 AM
>     *Subject: *API documentation
>
>     Hi All,
>
>     Is there somewhere where all the ovirt (& related components) API
>     documentation resides? I've had a look and i'm willing to say that
>     i'm going blind but I couldn't find it.
>
>     Any clues?
>
>     Tks
>     Geoff
>
>     _______________________________________________
>     Arch mailing list
>     Arch at ovirt.org
>     http://lists.ovirt.org/mailman/listinfo/arch
>
>
>
>
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch


-- 
Cheers
Douglas


From danken at redhat.com  Thu Dec 27 12:14:06 2012
From: danken at redhat.com (Dan Kenigsberg)
Date: Thu, 27 Dec 2012 14:14:06 +0200
Subject: feature suggestion: initial generation of management network
In-Reply-To: <27623755.252.1356445712988.JavaMail.javamailuser@localhost>
References: <20121225122722.GG7274@redhat.com>
	<27623755.252.1356445712988.JavaMail.javamailuser@localhost>
Message-ID: <20121227121406.GD8915@redhat.com>

On Tue, Dec 25, 2012 at 09:29:26AM -0500, Simon Grinberg wrote:
> 
> 
> ----- Original Message -----
> > From: "Dan Kenigsberg" <danken at redhat.com>
> > To: "arch" <arch at ovirt.org>
> > Sent: Tuesday, December 25, 2012 2:27:22 PM
> > Subject: feature suggestion: initial generation of management network
> > 
> > Current condition:
> > ==================
> > The management network, named ovirtmgmt, is created during host
> > bootstrap. It consists of a bridge device, connected to the network
> > device that was used to communicate with Engine (nic, bonding or
> > vlan).
> > It inherits its ip settings from the latter device.
> > 
> > Why Is the Management Network Needed?
> > =====================================
> > Understandably, some may ask why do we need to have a management
> > network - why having a host with IPv4 configured on it is not enough.
> > The answer is twofold:
> > 1. In oVirt, a network is an abstraction of the resources required
> > for
> >    connectivity of a host for a specific usage. This is true for the
> >    management network just as it is for VM network or a display
> >    network.
> >    The network entity is the key for adding/changing nics and IP
> >    address.
> > 2. In many occasions (such as small setups) the management network is
> >    used as a VM/display network as well.
> > 
> > Problems in current connectivity:
> > ================================
> > According to alonbl of ovirt-host-deploy fame, and with no conflict
> > to
> > my own experience, creating the management network is the most
> > fragile,
> > error-prone step of bootstrap.
> 
> +1, 
> I've raise that repeatedly in the past, bootstrap should not create the management network but pick up the existing configuration and let the engine override later with it's own configuration if it differs , I'm glad that we finally get to that. 
> 
> > 
> > Currently it always creates a bridged network (even if the DC
> > requires a
> > non-bridged ovirtmgmt), it knows nothing about the defined MTU for
> > ovirtmgmt, it uses ping to guess on top of which device to build (and
> > thus requires Vdsm-to-Engine reverse connectivity), and is the sole
> > remaining user of the addNetwork/vdsm-store-net-conf scripts.
> > 
> > Suggested feature:
> > ==================
> > Bootstrap would avoid creating a management network. Instead, after
> > bootstrapping a host, Engine would send a getVdsCaps probe to the
> > installed host, receiving a complete picture of the network
> > configuration on the host. Among this picture is the device that
> > holds
> > the host's management IP address.
> > 
> > Engine would send setupNetwork command to generate ovirtmgmt with
> > details devised from this picture, and according to the DC definition
> > of
> > ovirtmgmt.  For example, if Vdsm reports:
> > 
> > - vlan bond4.3000 has the host's IP, configured to use dhcp.
> > - bond4 is comprises eth2 and eth3
> > - ovirtmgmt is defined as a VM network with MTU 9000
> > 
> > then Engine sends the likes of:
> >   setupNetworks(ovirtmgmt: {bridged=True, vlan=3000, iface=bond4,
> >                 bonding=bond4: {eth2,eth3}, MTU=9000)
> 
> Just one comment here, 
> In order to save time and confusion - if the ovirtmgmt is defined with default values meaning the user did not bother to touch it, let it pick up the VLAN configuration from the first host added in the Data Center. 
> 
> Otherwise, you may override the host VLAN and loose connectivity.
> 
> This will also solve the situation many users encounter today. 
> 1. The engine in on a host that actually has VLAN defined 
> 2. The ovirtmgmt network was not updated in the DC
> 3. A host, with VLAN already defined is added - everything works fine
> 4. Any number of hosts are now added, again everything seems to work fine. 
> 
> But, now try to use setupNetworks, and you'll find out that you can't do much on the interface that contains the ovirtmgmt since the definition does not match. You can't sync (Since this will remove the VLAN and cause connectivity lose) you can't add more networks on top since it already has non-VLAN network on top according to the DC definition, etc.
> 
> On the other hand you can't update the ovirtmgmt definition on the DC since there are clusters in the DC that use the network.
> 
> The only workaround not involving DB hack to change the VLAN on the network is to:
> 1. Create new DC 
> 2. Do not use the wizard that pops up to create your cluster.
> 3. Modify the ovirtmgmt network to have VLANs 
> 4. Now create a cluster and add your hosts.
> 
> If you insist on using the default DC and cluster then before adding the first host, create an additional DC and move the Default cluster over there. You may then change the network on the Default cluster and then move the Default cluster back
> 
> Both are ugly. And should be solved by the proposal above. 
> 
> We do something similar for the Default cluster CPU level, where we set the intial level based on the first host added to the cluster. 

I'm not sure what Engine has for Default cluster CPU level. But I have
reservation of the hysteresis in your proposal - after a host is added,
the DC cannot forget ovirtmgmt's vlan.

How about letting the admin edit ovirtmgmt's vlan in the DC level, thus
rendering all hosts out-of-sync. The the admin could manually, or
through a script, or in the future through a distributed operation, sync
all the hosts to the definition?

Dan.

> 
> > 
> > A call to setSafeNetConfig would wrap the network configuration up.
> > 
> > Currently, the host underegoes a reboot as the last step of
> > bootstrap.
> > This allows us to verify immediately if the host would be accessible
> > post-boot using its new network configuration. If we want to maintain
> > this, Engine would need to send a fenceNode request.
> > 
> > Benefits:
> > =========
> > - Simplified bootstrapping
> > - Simplified ovirt-node registration (similar ovirtmgmt-generation
> > logic lies there).
> > - Host installation ends with an ovirtmgmt network that matches DC
> >   definition (bridged-ness, mtu, vlan).
> > - vdsm-to-engine connectivity is not required.
> > 
> > Drawbacks:
> > ==========
> > - We need to implement new Engine logic for devising ovirtmgmt
> > definition out of getVdsCaps output.
> 
> That is not a drawback - it's just writing code. Drawback as I see it, is within the suggested feature on the final behaviour and code. 
> 
> > - ... your input is welcome here
> > 
> > Missing:
> > ========
> > A wiki feature page for this new behavior.
> > 
> > 
> > _______________________________________________
> > Arch mailing list
> > Arch at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/arch
> > 


From simon at redhat.com  Thu Dec 27 12:36:40 2012
From: simon at redhat.com (Simon Grinberg)
Date: Thu, 27 Dec 2012 07:36:40 -0500 (EST)
Subject: feature suggestion: initial generation of management network
In-Reply-To: <20121227121406.GD8915@redhat.com>
Message-ID: <11330867.78.1356611742783.JavaMail.javamailuser@localhost>



----- Original Message -----
> From: "Dan Kenigsberg" <danken at redhat.com>
> To: "Simon Grinberg" <simon at redhat.com>
> Cc: "arch" <arch at ovirt.org>
> Sent: Thursday, December 27, 2012 2:14:06 PM
> Subject: Re: feature suggestion: initial generation of management network
> 
> On Tue, Dec 25, 2012 at 09:29:26AM -0500, Simon Grinberg wrote:
> > 
> > 
> > ----- Original Message -----
> > > From: "Dan Kenigsberg" <danken at redhat.com>
> > > To: "arch" <arch at ovirt.org>
> > > Sent: Tuesday, December 25, 2012 2:27:22 PM
> > > Subject: feature suggestion: initial generation of management
> > > network
> > > 
> > > Current condition:
> > > ==================
> > > The management network, named ovirtmgmt, is created during host
> > > bootstrap. It consists of a bridge device, connected to the
> > > network
> > > device that was used to communicate with Engine (nic, bonding or
> > > vlan).
> > > It inherits its ip settings from the latter device.
> > > 
> > > Why Is the Management Network Needed?
> > > =====================================
> > > Understandably, some may ask why do we need to have a management
> > > network - why having a host with IPv4 configured on it is not
> > > enough.
> > > The answer is twofold:
> > > 1. In oVirt, a network is an abstraction of the resources
> > > required
> > > for
> > >    connectivity of a host for a specific usage. This is true for
> > >    the
> > >    management network just as it is for VM network or a display
> > >    network.
> > >    The network entity is the key for adding/changing nics and IP
> > >    address.
> > > 2. In many occasions (such as small setups) the management
> > > network is
> > >    used as a VM/display network as well.
> > > 
> > > Problems in current connectivity:
> > > ================================
> > > According to alonbl of ovirt-host-deploy fame, and with no
> > > conflict
> > > to
> > > my own experience, creating the management network is the most
> > > fragile,
> > > error-prone step of bootstrap.
> > 
> > +1,
> > I've raise that repeatedly in the past, bootstrap should not create
> > the management network but pick up the existing configuration and
> > let the engine override later with it's own configuration if it
> > differs , I'm glad that we finally get to that.
> > 
> > > 
> > > Currently it always creates a bridged network (even if the DC
> > > requires a
> > > non-bridged ovirtmgmt), it knows nothing about the defined MTU
> > > for
> > > ovirtmgmt, it uses ping to guess on top of which device to build
> > > (and
> > > thus requires Vdsm-to-Engine reverse connectivity), and is the
> > > sole
> > > remaining user of the addNetwork/vdsm-store-net-conf scripts.
> > > 
> > > Suggested feature:
> > > ==================
> > > Bootstrap would avoid creating a management network. Instead,
> > > after
> > > bootstrapping a host, Engine would send a getVdsCaps probe to the
> > > installed host, receiving a complete picture of the network
> > > configuration on the host. Among this picture is the device that
> > > holds
> > > the host's management IP address.
> > > 
> > > Engine would send setupNetwork command to generate ovirtmgmt with
> > > details devised from this picture, and according to the DC
> > > definition
> > > of
> > > ovirtmgmt.  For example, if Vdsm reports:
> > > 
> > > - vlan bond4.3000 has the host's IP, configured to use dhcp.
> > > - bond4 is comprises eth2 and eth3
> > > - ovirtmgmt is defined as a VM network with MTU 9000
> > > 
> > > then Engine sends the likes of:
> > >   setupNetworks(ovirtmgmt: {bridged=True, vlan=3000, iface=bond4,
> > >                 bonding=bond4: {eth2,eth3}, MTU=9000)
> > 
> > Just one comment here,
> > In order to save time and confusion - if the ovirtmgmt is defined
> > with default values meaning the user did not bother to touch it,
> > let it pick up the VLAN configuration from the first host added in
> > the Data Center.
> > 
> > Otherwise, you may override the host VLAN and loose connectivity.
> > 
> > This will also solve the situation many users encounter today.
> > 1. The engine in on a host that actually has VLAN defined
> > 2. The ovirtmgmt network was not updated in the DC
> > 3. A host, with VLAN already defined is added - everything works
> > fine
> > 4. Any number of hosts are now added, again everything seems to
> > work fine.
> > 
> > But, now try to use setupNetworks, and you'll find out that you
> > can't do much on the interface that contains the ovirtmgmt since
> > the definition does not match. You can't sync (Since this will
> > remove the VLAN and cause connectivity lose) you can't add more
> > networks on top since it already has non-VLAN network on top
> > according to the DC definition, etc.
> > 
> > On the other hand you can't update the ovirtmgmt definition on the
> > DC since there are clusters in the DC that use the network.
> > 
> > The only workaround not involving DB hack to change the VLAN on the
> > network is to:
> > 1. Create new DC
> > 2. Do not use the wizard that pops up to create your cluster.
> > 3. Modify the ovirtmgmt network to have VLANs
> > 4. Now create a cluster and add your hosts.
> > 
> > If you insist on using the default DC and cluster then before
> > adding the first host, create an additional DC and move the
> > Default cluster over there. You may then change the network on the
> > Default cluster and then move the Default cluster back
> > 
> > Both are ugly. And should be solved by the proposal above.
> > 
> > We do something similar for the Default cluster CPU level, where we
> > set the intial level based on the first host added to the cluster.
> 
> I'm not sure what Engine has for Default cluster CPU level. But I
> have
> reservation of the hysteresis in your proposal - after a host is
> added,
> the DC cannot forget ovirtmgmt's vlan.
> 
> How about letting the admin edit ovirtmgmt's vlan in the DC level,
> thus
> rendering all hosts out-of-sync. The the admin could manually, or
> through a script, or in the future through a distributed operation,
> sync
> all the hosts to the definition?

Usually if you do that you will loose connectivity to the hosts.
I'm not insisting on the automatic adjustment of the ovirtmgmt network to match the hosts' (that is just a nice touch) we can take the allow edit approach. 

But allow to change VLAN on the ovirtmgmt network will indeed solve the issue I'm trying to solve while creating another issue of user expecting that we'll be able to re-tag the host from the engine side, which is challenging to do.

On the other hand, if we allow to change the VLAN as long as the change matches the hosts' configuration, it will both solve the issue while not eluding the user to think that we really can solve the chicken and egg issue of re-tag the entire system. 

Now with the above ability you do get a flow to do the re-tag. 
1. Place all the hosts in maintenance 
2. Re-tag the ovirtmgmt on all the hosts 
3. Re-tag the hosts on which the engine on
4. Activate the hosts - this should work well now since connectivity exist
5. Change the tag on ovirtmgmt on the engine to match the hosts' 

Simple and clear process.

When the workaround of creating another DC was not possible since the system was already long in use and the need was re-tag of the network the above is what I've recommended in the, except that steps 4-5 where done as:
4. Stop the engine 
5. Change the tag in the DB
6. Start the engine 
7. Activate the hosts
 
> 
> Dan.
> 
> > 
> > > 
> > > A call to setSafeNetConfig would wrap the network configuration
> > > up.
> > > 
> > > Currently, the host underegoes a reboot as the last step of
> > > bootstrap.
> > > This allows us to verify immediately if the host would be
> > > accessible
> > > post-boot using its new network configuration. If we want to
> > > maintain
> > > this, Engine would need to send a fenceNode request.
> > > 
> > > Benefits:
> > > =========
> > > - Simplified bootstrapping
> > > - Simplified ovirt-node registration (similar
> > > ovirtmgmt-generation
> > > logic lies there).
> > > - Host installation ends with an ovirtmgmt network that matches
> > > DC
> > >   definition (bridged-ness, mtu, vlan).
> > > - vdsm-to-engine connectivity is not required.
> > > 
> > > Drawbacks:
> > > ==========
> > > - We need to implement new Engine logic for devising ovirtmgmt
> > > definition out of getVdsCaps output.
> > 
> > That is not a drawback - it's just writing code. Drawback as I see
> > it, is within the suggested feature on the final behaviour and
> > code.
> > 
> > > - ... your input is welcome here
> > > 
> > > Missing:
> > > ========
> > > A wiki feature page for this new behavior.
> > > 
> > > 
> > > _______________________________________________
> > > Arch mailing list
> > > Arch at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/arch
> > > 
>