[Openstack] Hypervisor support matrix: differences between XenServer and KVM
Hi all, as I can see in the hypervisor's support matrix page ( http://wiki.openstack.org/HypervisorSupportMatrix ) there are a few differences between the XenSever/XCP's feature list and the KVM's one. Brian Lamar has been so kind to explain me what the missing resize feature means ( https://answers.launchpad.net/nova/+question/169814 ): is there any plan to fix this gap? Now I'm not sure about what implies the missing Firewall rules and Security Groups in Xen support. Does this means that there's no way to generate iptables rules on xen instances via euca-tools? Do xen instances need to have an onboard firewall? More in general, how can I check if an api method will be supported in my installation? Thanks a lot. Giuseppe ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] A possible alternative to Gerrit ...
Taking a bit of a step back, it seems to me that the biggest thing that prevents us from using a pure github workflow is the absolute requirement of a gated trunk. Perhaps a better question to ask weather or not this should be an absolute requirement. For me, it is a nice to have, but shouldn't be an absolute requirement. Perhaps a good issue for the PPB to take up? Thoughts? -- Chuck On Sat, Sep 3, 2011 at 4:42 PM, Josh Kearney j...@jk0.org wrote: I don't intend to fan the fumes here, but I think the point we are trying to make is that the decision to use Gerrit was made before most of the community was even aware of it -- much less having a chance to come up with a solution like Sandy did (which, IMHO, is far more practical than the Gerrit workflow). How much more resistance will it take before we can consider an alternative? Would a poll be out of the question? On Sep 3, 2011, at 3:50 PM, Thierry Carrez thie...@openstack.org wrote: Jay Payne wrote: Can we dial down the drama a bit? It's things like this that will discourage people from submitting new ideas. Calling just the introduction of a new idea a revolt is a diservice to the community. Well, maybe revolt is not the best term, but this is about resisting the transition to Gerrit -- one can only regret that this new idea wasn't introduced in the previous months, while the Gerrit solution was still under development and while we hadn't start transitioning core projects to that new system. -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] A possible alternative to Gerrit ...
I actually didn't plan on responding all that much on this conversation. We had months of discussion and debate about this, weeks upon weeks of discussion in the PPB about project autonomy and tooling, and the decision has been made. I find it a bit unfortunate that all the people saying Gerrit is terrible and that we should just use GitHub haven't done a single review or change request in any of the projects that are currently using the Gerrit/Git toolset that has been decided will be used for core OpenStack projects. The coarse status granularity of GitHub's pull request is a non-starter for automated patch queue management and a gated trunk. Period. Solutions such as roundabout and hubcap must use hacks such as looking in review comments for one or more lgtms to determine if a commit is approved to be merged. This is not a robust solution and is prone to errors. I might also add that the integration functionality that Gerrit has with Launchpad (automated bug status updating, automatic blueprints status tracking/updating) is very good. The CI team keeps all the code for this integration work here: https://github.com/openstack/openstack-ci. For those of you who have never actually worked with Gerrit, and are complaining about how terrible it is, I would suggest working through a simple change request and patch review workflow for the OpenStack CI project and provide some useful suggestions on ways it can be improved. Lots of things, including the user interface, can be modified and improved. I look forward to seeing your energy and enthusiasm for these matters transformed into productive and helpful change requests for the code in the OpenStack CI project. Cheers, jay On Fri, Sep 2, 2011 at 7:16 AM, Sandy Walsh sandy.wa...@rackspace.com wrote: Understood and thanks for the clarification Thierry ... just a developer scratching an itch. Although it could be argued that it was a bit of a bait-n-switch on our ultimate github usage and the suitability of Gerrit. But as you say, let's wait for the guys to respond. Thanks -S From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net [openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf of Thierry Carrez [thie...@openstack.org] Sent: Friday, September 02, 2011 4:09 AM To: openstack@lists.launchpad.net Subject: Re: [Openstack] A possible alternative to Gerrit ... Sandy Walsh wrote: Last night I did some hacking on HubCap. HubCap is a simple script that monitors Pull Requests in GitHub. It spits out a static HTML page of the requests workflow status. [...] I won't speak on behalf of Monty Taylor, Jim Blair (or Jay) who are unfortunately all in limited availability while this anti-Gerrit revolt is being sent on the ML. Please wait for their reply, which should come soon. Not judging on the merits of that particular option, as a PPB member, I just would like to stress that we voted on having a single set of tools for core projects, so each project is not really free to choose its code review tool. The codehosting/codereview set of tools that was recently chosen is git/github/Gerrit... Glance and Keystone are already migrated, and Swift, Nova and Dashboard are scheduled for migration. So your alternative appears to be a bit late. Though we haven't formally voted on that, I think it's also general PPB feeling that we shouldn't change systems every 6 months (or every 2 months) just because something cooler exists. Switching systems might not be costly for you, but it's definitely costly for others (the openstack-ci team obviously, but also release management) -- and we should all have better use of our limited time. Regards, -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] A possible alternative to Gerrit ...
On Sun, Sep 4, 2011 at 12:39 PM, Chuck Thier cth...@gmail.com wrote: Taking a bit of a step back, it seems to me that the biggest thing that prevents us from using a pure github workflow is the absolute requirement of a gated trunk. I think the big step backwards would be not having a gated trunk. Humans are prone to errors. In a project of any substantial size, automated patch queue management and a trunk gated on specific policies around test failures means fewer merge errors. Cheers, -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] A possible alternative to Gerrit ...
The coarse status granularity of GitHub's pull request is a non-starter for automated patch queue management and a gated trunk. Period. Solutions such as roundabout and hubcap must use hacks such as looking in review comments for one or more lgtms to determine if a commit is approved to be merged. This is not a robust solution and is prone to errors. I agree. Hubcap proposes to fix this course granularity. That's the whole point. Ttx has informed me that there are nuances to the merge process that I'm perhaps missing. I understand there are issues with cherry picking, etc that github does not excel at. I'd love to understand these requirements in greater depth. And, regarding how hubcap would be any more error prone/robust than any other solution, I have to plead ignorance,. Can you elaborate on these two points please? Thanks, -S PS I think it's very impressive the work that has gone into gerrit/jenkins integration. But from the (admittedly limited) merges/reviews I've done so far it seems overly complex. But, don't confuse my ignorance of the requirements as a slight against the efforts thus far. And, I have to say, I'm certainly not a github/git fanboy. My personal preference is definitely in the bzr/lp house. I would expect any solution to be at least as good at that. This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Proposal: URIs for X-Auth-Header Keystone tokens
Still getting up to speed on the finer points of keystone, but makes sense to
me.
Is X-Auth-Token keystone-specific? If so, calling it something like
Keystone-Token would be better (X- is falling out of favour; see
http://tools.ietf.org/html/draft-saintandre-xdash-03). That'd also avoid
problems with people expecting the other format.
Finally, if you're going to make it a URI, best to enclose it in quotes - URIs
can contain commas, which can be a delimiter in HTTP headers (especially if
multiple tokens might be allowed).
E.g.,
Keystone-Token:
https://keystone.server/tenants/fa8426a0-8eaf-4d22-8e13-7c1b16a9370c;
Cheers,
P.S. If these are going to show up in other contexts, it *might* make sense to
define keystone-token as a link relation http://tools.ietf.org/html/rfc5988,
giving you:
Link: https://keystone.server/tenants/fa8426a0-8eaf-4d22-8e13-7c1b16a9370c;
rel=keystone-token
On 04/09/2011, at 2:39 AM, Bryan Taylor wrote:
I propose identifying tokens by their full keystone URI within X-Auth-Token
header. EG: instead of
X-Auth-Token: fa8426a0-8eaf-4d22-8e13-7c1b16a9370c
we would do
X-Auth-Token:
https://keystone.server/tenants/fa8426a0-8eaf-4d22-8e13-7c1b16a9370c
This has the advantage of allowing federated tokens, and allowing APIs and
even resources to use the auth server in access decisions. A given service
would maintain a whitelists of keystone servers. The service would take the
request, get the token, and verify that the host of the token URI matches one
from the appropriate whitelist, and then do a GET on the token per the
keystone API.
For example, consider rackspace. We might have 3 keystone servers:
region1.customer.keystone
region2.customer.keystone
employee.keystone
The management API might set it's whitelist to {employee.keystone}, while the
public APIs could whitelist all three, or maybe just the first two.
This creates three ways to do remote federation.
1) Each service could simply add remote keystone APIs to its whitelists.
2) A whitelisted keystone server return REDIRECT, which services implicitly
trust
3) A whitelisted keystone server could forward the request directly
Items 2 and 3 might be facilitated by adding an @host string to the end of
the token to allow the keystone implementation to map the token to its
source. Eg: if the service receives a token that is not from a whitelisted
client, such as
https://keystone.utexas.edu/tenants/fa8426a0-8eaf-4d22-8e13-7c1b16a9370c
then it mutate the token to hit a trusted keystone implementation:
https://keystone.server/tenants/fa8426a0-8eaf-4d22-8e13-7c1b16a93...@keystone.utexas.edu
The keystone.server implementation could verify the trust relationship with
keystone.utexas.edu and redirect or forward back to the original. This would
allow remote federations to be controlled by the trusted keystone servers in
a way that a client can leverage with no special knowledge – they just auth
against their normal keystone servers and proceed.
This email may include confidential information. If you received it in error,
please delete it.
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
--
Mark Nottingham http://www.mnot.net/
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Proposal: URIs for X-Auth-Header Keystone tokens
Love it.
Link:
https://keystone.server/tokens/fa8426a0-8eaf-4d22-8e13-7c1b16a9370c;
rel=keystone-token
Fixed: s/tenants/tokens/ (my bad).
On 9/4/11 7:40 PM, Mark Nottingham m...@mnot.net wrote:
Still getting up to speed on the finer points of keystone, but makes
sense to me.
Is X-Auth-Token keystone-specific? If so, calling it something like
Keystone-Token would be better (X- is falling out of favour; see
http://tools.ietf.org/html/draft-saintandre-xdash-03). That'd also
avoid problems with people expecting the other format.
Finally, if you're going to make it a URI, best to enclose it in quotes -
URIs can contain commas, which can be a delimiter in HTTP headers
(especially if multiple tokens might be allowed).
E.g.,
Keystone-Token:
https://keystone.server/tenants/fa8426a0-8eaf-4d22-8e13-7c1b16a9370c;
Cheers,
P.S. If these are going to show up in other contexts, it *might* make
sense to define keystone-token as a link relation
http://tools.ietf.org/html/rfc5988, giving you:
Link:
https://keystone.server/tenants/fa8426a0-8eaf-4d22-8e13-7c1b16a9370c;
rel=keystone-token
On 04/09/2011, at 2:39 AM, Bryan Taylor wrote:
I propose identifying tokens by their full keystone URI within
X-Auth-Token header. EG: instead of
X-Auth-Token: fa8426a0-8eaf-4d22-8e13-7c1b16a9370c
we would do
X-Auth-Token:
https://keystone.server/tenants/fa8426a0-8eaf-4d22-8e13-7c1b16a9370c
This has the advantage of allowing federated tokens, and allowing APIs
and even resources to use the auth server in access decisions. A given
service would maintain a whitelists of keystone servers. The service
would take the request, get the token, and verify that the host of the
token URI matches one from the appropriate whitelist, and then do a GET
on the token per the keystone API.
For example, consider rackspace. We might have 3 keystone servers:
region1.customer.keystone
region2.customer.keystone
employee.keystone
The management API might set it's whitelist to {employee.keystone},
while the public APIs could whitelist all three, or maybe just the first
two.
This creates three ways to do remote federation.
1) Each service could simply add remote keystone APIs to its
whitelists.
2) A whitelisted keystone server return REDIRECT, which services
implicitly trust
3) A whitelisted keystone server could forward the request directly
Items 2 and 3 might be facilitated by adding an @host string to the
end of the token to allow the keystone implementation to map the token
to its source. Eg: if the service receives a token that is not from a
whitelisted client, such as
https://keystone.utexas.edu/tenants/fa8426a0-8eaf-4d22-8e13-7c1b16a9370c
then it mutate the token to hit a trusted keystone implementation:
https://keystone.server/tenants/fa8426a0-8eaf-4d22-8e13-7c1b16a9370c@keys
tone.utexas.edu
The keystone.server implementation could verify the trust relationship
with keystone.utexas.edu and redirect or forward back to the original.
This would allow remote federations to be controlled by the trusted
keystone servers in a way that a client can leverage with no special
knowledge they just auth against their normal keystone servers and
proceed.
This email may include confidential information. If you received it in
error, please delete it.
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
--
Mark Nottingham http://www.mnot.net/
This email may include confidential information. If you received it in error,
please delete it.
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Proposal: URIs for X-Auth-Header Keystone tokens
Hmmm, I'm thinking more about this. Would using the Link: header break the
ability to use the Vary header? I can't Vary on a Link header based on
it's rel attribute.
So maybe Keystone-Token is the way to go. I could see intermediaries doing
the token resolution and adding headers like Keystone-User and
Keystone-Tenant which could also be used in Vary Headers.
On 9/4/11 8:06 PM, Bryan Taylor btay...@rackspace.com wrote:
Love it.
Link:
https://keystone.server/tokens/fa8426a0-8eaf-4d22-8e13-7c1b16a9370c;
rel=keystone-token
Fixed: s/tenants/tokens/ (my bad).
On 9/4/11 7:40 PM, Mark Nottingham m...@mnot.net wrote:
Still getting up to speed on the finer points of keystone, but makes
sense to me.
Is X-Auth-Token keystone-specific? If so, calling it something like
Keystone-Token would be better (X- is falling out of favour; see
http://tools.ietf.org/html/draft-saintandre-xdash-03). That'd also
avoid problems with people expecting the other format.
Finally, if you're going to make it a URI, best to enclose it in quotes -
URIs can contain commas, which can be a delimiter in HTTP headers
(especially if multiple tokens might be allowed).
E.g.,
Keystone-Token:
https://keystone.server/tenants/fa8426a0-8eaf-4d22-8e13-7c1b16a9370c;
Cheers,
P.S. If these are going to show up in other contexts, it *might* make
sense to define keystone-token as a link relation
http://tools.ietf.org/html/rfc5988, giving you:
Link:
https://keystone.server/tenants/fa8426a0-8eaf-4d22-8e13-7c1b16a9370c;
rel=keystone-token
On 04/09/2011, at 2:39 AM, Bryan Taylor wrote:
I propose identifying tokens by their full keystone URI within
X-Auth-Token header. EG: instead of
X-Auth-Token: fa8426a0-8eaf-4d22-8e13-7c1b16a9370c
we would do
X-Auth-Token:
https://keystone.server/tenants/fa8426a0-8eaf-4d22-8e13-7c1b16a9370c
This has the advantage of allowing federated tokens, and allowing APIs
and even resources to use the auth server in access decisions. A given
service would maintain a whitelists of keystone servers. The service
would take the request, get the token, and verify that the host of the
token URI matches one from the appropriate whitelist, and then do a GET
on the token per the keystone API.
For example, consider rackspace. We might have 3 keystone servers:
region1.customer.keystone
region2.customer.keystone
employee.keystone
The management API might set it's whitelist to {employee.keystone},
while the public APIs could whitelist all three, or maybe just the first
two.
This creates three ways to do remote federation.
1) Each service could simply add remote keystone APIs to its
whitelists.
2) A whitelisted keystone server return REDIRECT, which services
implicitly trust
3) A whitelisted keystone server could forward the request directly
Items 2 and 3 might be facilitated by adding an @host string to the
end of the token to allow the keystone implementation to map the token
to its source. Eg: if the service receives a token that is not from a
whitelisted client, such as
https://keystone.utexas.edu/tenants/fa8426a0-8eaf-4d22-8e13-7c1b16a9370c
then it mutate the token to hit a trusted keystone implementation:
https://keystone.server/tenants/fa8426a0-8eaf-4d22-8e13-7c1b16a9370c@key
s
tone.utexas.edu
The keystone.server implementation could verify the trust relationship
with keystone.utexas.edu and redirect or forward back to the original.
This would allow remote federations to be controlled by the trusted
keystone servers in a way that a client can leverage with no special
knowledge they just auth against their normal keystone servers and
proceed.
This email may include confidential information. If you received it in
error, please delete it.
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
--
Mark Nottingham http://www.mnot.net/
This email may include confidential information. If you received it in
error, please delete it.
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
This email may include confidential information. If you received it in error,
please delete it.
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Proposal: URIs for X-Auth-Header Keystone tokens
Good point; Link makes more sense on a response.
Cheers,
On 05/09/2011, at 12:49 PM, Bryan Taylor wrote:
Hmmm, I'm thinking more about this. Would using the Link: header break the
ability to use the Vary header? I can't Vary on a Link header based on
it's rel attribute.
So maybe Keystone-Token is the way to go. I could see intermediaries doing
the token resolution and adding headers like Keystone-User and
Keystone-Tenant which could also be used in Vary Headers.
On 9/4/11 8:06 PM, Bryan Taylor btay...@rackspace.com wrote:
Love it.
Link:
https://keystone.server/tokens/fa8426a0-8eaf-4d22-8e13-7c1b16a9370c;
rel=keystone-token
Fixed: s/tenants/tokens/ (my bad).
On 9/4/11 7:40 PM, Mark Nottingham m...@mnot.net wrote:
Still getting up to speed on the finer points of keystone, but makes
sense to me.
Is X-Auth-Token keystone-specific? If so, calling it something like
Keystone-Token would be better (X- is falling out of favour; see
http://tools.ietf.org/html/draft-saintandre-xdash-03). That'd also
avoid problems with people expecting the other format.
Finally, if you're going to make it a URI, best to enclose it in quotes -
URIs can contain commas, which can be a delimiter in HTTP headers
(especially if multiple tokens might be allowed).
E.g.,
Keystone-Token:
https://keystone.server/tenants/fa8426a0-8eaf-4d22-8e13-7c1b16a9370c;
Cheers,
P.S. If these are going to show up in other contexts, it *might* make
sense to define keystone-token as a link relation
http://tools.ietf.org/html/rfc5988, giving you:
Link:
https://keystone.server/tenants/fa8426a0-8eaf-4d22-8e13-7c1b16a9370c;
rel=keystone-token
On 04/09/2011, at 2:39 AM, Bryan Taylor wrote:
I propose identifying tokens by their full keystone URI within
X-Auth-Token header. EG: instead of
X-Auth-Token: fa8426a0-8eaf-4d22-8e13-7c1b16a9370c
we would do
X-Auth-Token:
https://keystone.server/tenants/fa8426a0-8eaf-4d22-8e13-7c1b16a9370c
This has the advantage of allowing federated tokens, and allowing APIs
and even resources to use the auth server in access decisions. A given
service would maintain a whitelists of keystone servers. The service
would take the request, get the token, and verify that the host of the
token URI matches one from the appropriate whitelist, and then do a GET
on the token per the keystone API.
For example, consider rackspace. We might have 3 keystone servers:
region1.customer.keystone
region2.customer.keystone
employee.keystone
The management API might set it's whitelist to {employee.keystone},
while the public APIs could whitelist all three, or maybe just the first
two.
This creates three ways to do remote federation.
1) Each service could simply add remote keystone APIs to its
whitelists.
2) A whitelisted keystone server return REDIRECT, which services
implicitly trust
3) A whitelisted keystone server could forward the request directly
Items 2 and 3 might be facilitated by adding an @host string to the
end of the token to allow the keystone implementation to map the token
to its source. Eg: if the service receives a token that is not from a
whitelisted client, such as
https://keystone.utexas.edu/tenants/fa8426a0-8eaf-4d22-8e13-7c1b16a9370c
then it mutate the token to hit a trusted keystone implementation:
https://keystone.server/tenants/fa8426a0-8eaf-4d22-8e13-7c1b16a9370c@key
s
tone.utexas.edu
The keystone.server implementation could verify the trust relationship
with keystone.utexas.edu and redirect or forward back to the original.
This would allow remote federations to be controlled by the trusted
keystone servers in a way that a client can leverage with no special
knowledge they just auth against their normal keystone servers and
proceed.
This email may include confidential information. If you received it in
error, please delete it.
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
--
Mark Nottingham http://www.mnot.net/
This email may include confidential information. If you received it in
error, please delete it.
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
This email may include confidential information. If you received it in error,
please delete it.
--
Mark Nottingham http://www.mnot.net/
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] A possible alternative to Gerrit ...
Jay, On Sep 4, 2011, at 10:52 AM, Jay Pipes wrote: I actually didn't plan on responding all that much on this conversation. We had months of discussion and debate about this, weeks upon weeks of discussion in the PPB about project autonomy and tooling, and the decision has been made. I find it a bit unfortunate that all the people saying Gerrit is terrible and that we should just use GitHub haven't done a single review or change request in any of the projects that are currently using the Gerrit/Git toolset that has been decided will be used for core OpenStack projects. [...] I'm not sure this is true. A few people that I've seen speaking up have used it. I've been wanting to comment for a while, but I don't have a lot of ground to stand on, because I'm in the boat that you describe. I've not done a single review or change request with Gerrit yet. That said, I've seen a bit from those who have and I'm very much the opposite of excited about moving nova to it at some point, at least how it stands now. But leaving aside whether I like it or dislike it, what really bothers me is that there was discussion about moving things to github. And, I was 'ok' with that decision to do so despite preferring bzr and LP. My 'ok' was based on knowing how git, github pull requests, reviews, and so forth work. Now I feel like we're moving things to something to which I (and the community) never agreed. I never saw any discussion about Gerrit on the mailing list as far as is everyone cool with this? The first mention of it that I can find was July 18th regarding moving the CI repos. Doesn't seem like we were given much of an option. That really irks me. Above you say that has been decided will be used for the core OpenStack projects. So, I have to ask: 'Who decided?'. I must have missed something. And I want to be clear that I'm not meaning to put down anyone's efforts here. I'm positive a lot of hard work was put into the transition, and I do appreciate it. - Chris This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
