Re: [Openstack] [openstack-dev] baremetal nova boot issue

2013-10-11 Thread Joe Gordon 
On Fri, Oct 11, 2013 at 4:44 PM, Ravikanth Samprathi wrote:

> Hi
> I am trying to issue the boot command to provision baremetal server.  But
> i see the following error:
>
> Also, where can i get the bootstrap kernel and ramdisk images to boot into
> the baremetal?  And how to get the baremetal agent installed in the
> baremetal node?
>
> command:
> =
> root@os:/home/versa# nova boot --flavor 6 --image
> 39f4fd3b-15cc-4810-a808-e2c4764ba657 bm
> ERROR: The server has either erred or is incapable of performing the
> requested operation. (HTTP 500) (Request-ID:
> req-c463e02b-7c35-448e-b0a7-97d1c02c6088)
>
> The log is here:
> ==
>
> BATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYCEx607Bw1UBm9A87zNIcwDj5VsPwOrLmlq2EG3uWRfyjNoqSZo0jnK-VskJ29hAq1lPZsqe5bnhacWuUUr0nW+aAe-39pcGg9+lXPMOFQEjtRYdwUzhwMz05qm1yWjrdzXl0Hofv7ncdggF8SZbyBG0O68CRwzXRFXeSpGDrHeFw=="
>
> INFO (connectionpool:191) Starting new HTTP connection (1): 10.40.0.99
> DEBUG (connectionpool:283) "GET
> /v2/8a34123d83824f3ea52527c5a28ad81e/servers/36e71635-5f73-4895-87a9-6f1082e8cb6a
> HTTP/1.1" 500 128
> RESP: [500] {'date': 'Fri, 11 Oct 2013 23:43:43 GMT', 'content-length':
> '128', 'content-type': 'application/json; charset=UTF-8',
> 'x-compute-request-id': 'req-2fff698c-ddf2-47f1-ae82-47fb0dc67d41'}
> RESP BODY: {"computeFault": {"message": "The server has either erred or is
> incapable of performing the requested operation.", "code": 500}}
>
> DEBUG (shell:768) The server has either erred or is incapable of
> performing the requested operation. (HTTP 500) (Request-ID:
> req-2fff698c-ddf2-47f1-ae82-47fb0dc67d41)
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/dist-packages/novaclient/shell.py", line 765,
> in main
> OpenStackComputeShell().main(map(strutils.safe_decode, sys.argv[1:]))
>   File "/usr/lib/python2.7/dist-packages/novaclient/shell.py", line 701,
> in main
> args.func(self.cs, args)
>   File "/usr/lib/python2.7/dist-packages/novaclient/v1_1/shell.py", line
> 286, in do_boot
> server = cs.servers.get(info['id'])
>   File "/usr/lib/python2.7/dist-packages/novaclient/v1_1/servers.py", line
> 350, in get
> return self._get("/servers/%s" % base.getid(server), "server")
>   File "/usr/lib/python2.7/dist-packages/novaclient/base.py", line 140, in
> _get
> _resp, body = self.api.client.get(url)
>   File "/usr/lib/python2.7/dist-packages/novaclient/client.py", line 230,
> in get
> return self._cs_request(url, 'GET', **kwargs)
>   File "/usr/lib/python2.7/dist-packages/novaclient/client.py", line 217,
> in _cs_request
> **kwargs)
>   File "/usr/lib/python2.7/dist-packages/novaclient/client.py", line 199,
> in _time_request
> resp, body = self.request(url, method, **kwargs)
>   File "/usr/lib/python2.7/dist-packages/novaclient/client.py", line 193,
> in request
> raise exceptions.from_response(resp, body, url, method)
> ClientException: The server has either erred or is incapable of performing
> the requested operation. (HTTP 500) (Request-ID:
> req-2fff698c-ddf2-47f1-ae82-47fb0dc67d41)
> ERROR: The server has either erred or is incapable of performing the
> requested operation. (HTTP 500) (Request-ID:
> req-2fff698c-ddf2-47f1-ae82-47fb0dc67d41)
>
>
This is the novaclient log, what does the server say? You can search
nova-api.log for  req-2fff698c-ddf2-47f1-ae82-47fb0dc67d41 to see.


> Appreciate any  help.
> Thanks
> Ravi
>
>
> ___
> OpenStack-dev mailing list
> openstack-...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] [openstack-dev] baremetal nova boot issue

2013-10-11 Thread Joe Gordon 
gt; ute/contrib/security_groups.py", line 526, in show
> 3778 2013-10-11 16:43:43.514 4034 TRACE nova.api.openstack return
> self._show(req, resp_obj)
> 3779 2013-10-11 16:43:43.514 4034 TRACE nova.api.openstack   File
> "/usr/lib/python2.7/dist-packages/nova/api/openstack/comp
> ute/contrib/security_groups.py", line 522, in _show
> 3780 2013-10-11 16:43:43.514 4034 TRACE nova.api.openstack
> self._extend_servers(req, [resp_obj.obj['server']])
> 3781 2013-10-11 16:43:43.514 4034 TRACE nova.api.openstack   File
> "/usr/lib/python2.7/dist-packages/nova/api/openstack/comp
> ute/contrib/security_groups.py", line 487, in _extend_servers
> 3782 2013-10-11 16:43:43.514 4034 TRACE nova.api.openstack
> .get_instances_security_groups_bindings(context))
> 3783 2013-10-11 16:43:43.514 4034 TRACE nova.api.openstack   File
> "/usr/lib/python2.7/dist-packages/nova/network/security_g
> roup/quantum_driver.py", line 252, in get_instances_security_groups_bindings
> 3784 2013-10-11 16:43:43.514 4034 TRACE nova.api.openstack ports =
> quantum.list_ports().get('ports')
> 3785 2013-10-11 16:43:43.514 4034 TRACE nova.api.openstack   File
> "/usr/lib/python2.7/dist-packages/quantumclient/v2_0/clie nt.py", line
> 107, in with_params
> 3786 2013-10-11 16:43:43.514 4034 TRACE nova.api.openstack ret =
> self.function(instance, *args, **kwargs)
> 3787 2013-10-11 16:43:43.514 4034 TRACE nova.api.openstack   File
> "/usr/lib/python2.7/dist-packages/quantumclient/v2_0/clie nt.py", line
> 255, in list_ports
> 3788 2013-10-11 16:43:43.514 4034 TRACE nova.api.openstack **_params)
> 3789 2013-10-11 16:43:43.514 4034 TRACE nova.api.openstack   File
> "/usr/lib/python2.7/dist-packages/quantumclient/v2_0/clie nt.py", line
> 996, in list
> 3790 2013-10-11 16:43:43.514 4034 TRACE nova.api.openstack for r in
> self._pagination(collection, path, **params):
> 3791 2013-10-11 16:43:43.514 4034 TRACE nova.api.openstack   File
> "/usr/lib/python2.7/dist-packages/quantumclient/v2_0/clie nt.py", line
> 1009, in _pagination
> 3792 2013-10-11 16:43:43.514 4034 TRACE nova.api.openstack res =
> self.get(path, params=params)
> 3793 2013-10-11 16:43:43.514 4034 TRACE nova.api.openstack   File
> "/usr/lib/python2.7/dist-packages/quantumclient/v2_0/clie nt.py", line
> 982, in get
> 3794 2013-10-11 16:43:43.514 4034 TRACE nova.api.openstack
> headers=headers, params=params)
> 3795 2013-10-11 16:43:43.514 4034 TRACE nova.api.openstack   File
> "/usr/lib/python2.7/dist-packages/quantumclient/v2_0/clie nt.py", line
> 967, in retry_request
> 3796 2013-10-11 16:43:43.514 4034 TRACE nova.api.openstack
> headers=headers, params=params)
> 3797 2013-10-11 16:43:43.514 4034 TRACE nova.api.openstack   File
> "/usr/lib/python2.7/dist-packages/quantumclient/v2_0/clie nt.py", line
> 912, in do_request
> 3798 2013-10-11 16:43:43.514 4034 TRACE nova.api.openstack
> self._handle_fault_response(status_code, replybody)
> 3799 2013-10-11 16:43:43.514 4034 TRACE nova.api.openstack   File
> "/usr/lib/python2.7/dist-packages/quantumclient/v2_0/clie nt.py", line
> 893, in _handle_fault_response
> 3800 2013-10-11 16:43:43.514 4034 TRACE nova.api.openstack
> exception_handler_v20(status_code, des_error_body)
> 3801 2013-10-11 16:43:43.514 4034 TRACE nova.api.openstack   File
> "/usr/lib/python2.7/dist-packages/quantumclient/v2_0/clie nt.py", line
> 87, in exception_handler_v20
> 3802 2013-10-11 16:43:43.514 4034 TRACE nova.api.openstack
> message=message)
> 3803 2013-10-11 16:43:43.514 4034 TRACE nova.api.openstack
> QuantumClientException: [Errno 111] ECONNREFUSED
> 3804 2013-10-11 16:43:43.514 4034 TRACE nova.api.openstack
> 3805 2013-10-11 16:43:43.519 INFO nova.api.openstack
> [req-2fff698c-ddf2-47f1-ae82-47fb0dc67d41 251bd0a9388a477b9c24c99b223e
> 7b2a 8a34123d83824f3ea52527c5a28ad81e]
> http://10.40.0.99:8774/v2/8a34123d83824f3ea52527c5a28ad81e/servers/36e71635-5f7
> 3-4895-87a9-6f1082e8cb6a returned with HTTP 500
> 3806 2013-10-11 16:43:43.530 INFO nova.osapi_compute.wsgi.server
> [req-2fff698c-ddf2-47f1-ae82-47fb0dc67d41 251bd0a9388a477b
> 9c24c99b223e7b2a 8a34123d83824f3ea52527c5a28ad81e] 10.40.0.99 "GET
> /v2/8a34123d83824f3ea52527c5a28ad81e/servers/36e716
> 35-5f73-4895-87a9-6f1082e8cb6a HTTP/1.1" status: 500 len: 335 time:
> 0.1915259
> 3807
>
>
It looks like you were unable to connect to quantum.



> Than

Re: [Openstack] Promoting the role of +1 reviewers in our community

2013-10-30 Thread Joe Gordon 
On Wed, Oct 30, 2013 at 9:31 AM, Daniel P. Berrange wrote:

> On Wed, Oct 30, 2013 at 10:08:03AM +1100, Tom Fifield wrote:
> > Hi all,
> >
> > Recently, I did something crazy and got into the "top 10" reviewers
> > for OpenStack in a 30/60 day window. Admittedly, this was for
> > documentation  - which is quite a bit different than code - but the
> > experience did give me a small window of insight into the challenge
> > faced by our venerable core reviewers. It's a really tough job!
> >
> > One of the aspects that I noticed in doing so many reviews is that a
> > review was much easier to perform if another reviewer had been
> > through it beforehand. That is, a patch had gone through a couple of
> > -1 iterations to finally get a +1 before I saw it.
> >
> > This made me think a little about how much emphasis we place as a
> > community on +2 reviews. It can seem at times like they're the only
> > reviews we care about. Hell, I've even heard song lyrics from a
> > community member that imply this :D
> >
> > I think it's time to bend that focus slightly, and promote the role
> > of the +1 reviewers. Every review that a non-core reviewer does
> > helps reduce the burden of core reviewers just that little bit.
>
> It absolutely does, and is much appreciated by us core team
> members.
>
> > Do you see this too? How can we help encourage more +1 reviews?
>
>

Perhaps we should try making the top non-core reviewers more visible.
 Maybe list and thank the top x non-core reviewers and companies in the
weekly OpenStack newsletter?


> It is a tough question. You don't want to put up strict rules since that
> is typically counterproductive. Perhaps the biggest carrot to encourage
> more +1 reviews, is that it is a stepping stone to becoming a core team
> member. eg if you find yourself in the top-10 reviewers on nova for an
> extended period of time you'll likely get an invitation to become a
> core team member from Russell.
>
> Looking at our wiki page
>
>
> https://wiki.openstack.org/wiki/How_To_Contribute#If_you.27re_a_developer
>
> it is very much focused around that idea that you have to write code or
> do code fixes to become involved. It isn't really mentioning contribution
> via reviews at all. It merely mentions "learn gerrit" and use it to sign
> the CLA.
>
> Similarly this page
>
>   https://wiki.openstack.org/wiki/Gerrit_Workflow
>
> only mentions review in the context of what happens to *your* patch.
>
> I think that both those pages could be extended/re-written to strongly
> encourage contributors to participate in reviewing other people's patches.
>

++


>
> The "How to Contribute" page should explicitly list "reviewing code
> changes" as a primary way to contribute, and mention that it is one
> way to get on a path towards gaining the reputation needed to become
> a core team reviewer/member.
>
>

++

Currently the limiting factor in our workflow is reviewers, not patches or
patch authors.


> The "Gerrit Workflow" page should say something like
>
>   "While you are waiting for review feedback on changes you have
>submitted, you should browser other pending changes and provide
>review on them. By helping out with other reviews you will be
>decreasing the time delay for your own change to receive feedback"
>
> Daniel
> --
> |: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/:|
> |: http://libvirt.org  -o- http://virt-manager.org:|
> |: http://autobuild.org   -o- http://search.cpan.org/~danberr/:|
> |: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc:|
>
> ___
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] Bringing focus to the Operators and Users at the next summit

2013-12-16 Thread Joe Gordon 
On Sun, Dec 15, 2013 at 10:36 PM, Tristan Goode  wrote:

> I'm trying to establish a feedback loop "because" we (Operators, Users,
> etc)
> need to better present our actual real world, evidence based Operator,
> User,
> and even other input like Sales and Marketing experiences back into the
> development teams. Much of this does and will come from the great work of
> the UC, the User surveys, and especially the folks that have volunteered to
> analyse the survey results. I'm hoping to build on the survey analysis and
> collaboratively and constructively focus that to present a blueprint or
> roadmap with a "whole of OpenStack" scope. We can dig deeper into the user
> survey feedback and break beyond the bounds of the limited format of the
> user survey to seed the discussion. For me, the most valuable session in
> Hong Kong was the discussion led by Tim of the user survey. It was however,
> all too short.
>

Do you have any examples of what kind of feedback you would like to pass on
to developers (I was unable to attend Tim's discussion of the user survey)?
 Also just playing devils advocate here, but why not use our bug system to
provide feedback?


>
>
> > -Original Message-
> > From: Sean Dague [mailto:s...@dague.net]
> > Sent: Saturday, 14 December 2013 3:02 AM
> > To: openstack@lists.openstack.org
> > Subject: Re: [Openstack] Bringing focus to the Operators and Users at the
> > next
> > summit
> >
> > So not that I don't think this is a worth while thing, because I think it
> > is. But instead
> > of jumping to the solution of a User Day, it might be useful to figure
> out
> > what's
> > attempting to be solved.
> >
> > Is it?
> >
> > 1) get Users together to share best practices among themselves? Because
> > lots of
> > people have learned things, and want to bootstrap others.
> >
> > 2) get Users and Operators together to share best practices among
> > themselves?
> > Because ...
> >
> > 3) get Vendors and Users and Operators together? Because ...
> >
> > 4) get Developers and Users and Operators together? Because 
> >
> > I think if you start with defining the Because ... part, then the needed
> > parties, then
> > the odds of this being successful and useful to folks goes way up. It
> also
> > would give
> > people attending a reasonable expectation of what they are going to get
> > out of it.
> >
> > Because it would be a shame to set up #1, if most people thought they
> were
> > getting
> > #4 (which is basically what Lorin was proposing with his adopt a
> developer
> > idea),
> > then people being disappointed that they didn't get what they thought
> they
> > were
> > getting.
> >
> > The design summit works pretty well for the development community because
> > of
> > how narrowly it is scoped. So a critical mass in each of those rooms
> knows
> > when it's
> > getting off track and how to pull it back to something actionable at the
> > end.
> >
> >   -Sean
> >
> > On 12/13/2013 06:05 AM, Tristan Goode wrote:
> > > I guess what I'm trying to say by "Users and Operators" covers
> > > carriers and telcos. By User I mean folks that consume OpenStack
> > > resources and by Operator I mean folks that supply OpenStack
> > > resources. Maybe all can be called Users but whatever one calls it,
> > > what I mean basically is Non-Developers actually working on and with
> > > OpenStack. :)
> > >
> > >
> > >
> > > Cheers
> > >
> > > Tristan
> > >
> > >
> > >
> > > *From:*Kyle MacDonald [mailto:kyle.macdon...@gmail.com
> > > ]
> > > *Sent:* Thursday, 12 December 2013 7:02 PM
> > > *To:* Tristan Goode
> > > *Cc:* openstack@lists.openstack.org
> > > 
> > > *Subject:* Re: [Openstack] Bringing focus to the Operators and Users
> > > at the next summit
> > >
> > >
> > >
> > > Tristan
> > >
> > > I like this idea and agree it should be a priority. I do suggest the
> > > focus area be expanded (or a second focus day) to accommodate carriers
> > > and telcos and their operations needs (they are real operators).
> > >
> > >
> > >
> > > There is a ton of work being done by the leading telco's around NFV
> > > and SDN (many in emerging use cases) using OpenStack. I can very
> > > easily see "operations" being a killer issue and something that should
> > > be more broadly addressed. Last summit the forum for that track of
> > > discussions was by a vendor - next summit this area should be made
> > > more neutral and inclusive.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Kyle
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Dec 11, 2013, at 10:55 PM, Tristan Goode  > > > wrote:
> > >
> > > G'day OpenStackLand,
> > >
> > >
> > >
> > > I have an idea for the next summit to put forward...
> > >
> > >
> > >
> > > Like we have the various project design summit session days at the
> > > summits, I think it'd be really useful to have an Operators and
> > > User

Re: [Openstack] Bringing focus to the Operators and Users at the next summit

2013-12-16 Thread Joe Gordon 
On Mon, Dec 16, 2013 at 10:55 AM, Tim Bell  wrote:

>
>
> Specifying something as a bug needs to determine things like ‘what
> component should this be addressed in’ and describing the desired
> behaviour. Many of the comments from the survey describe the pain points,
> rather than the solutions. Upgrading is difficult, no mechanism to auto
> restart VMs on other hypervisors, monitoring frameworks, inconsistent
> options in command line tools and APIs, … equally, missing functional gaps
> do not fall well into the bug system.
>
>
>

Thanks for the examples.


>  I have received the feedback from operators when raising issues that
> they get the response ‘contributions are welcome’. Running an openstack
> cloud can be non-trivial, especially the big ones, and there is a need to
> appreciate that this effort is a significant part of the OpenStack
> community effort (along with the blogs, the documentation updates, the
> summit presentations).
>


While having a dev/operator session at the summit would be helpful, I don't
think meeting twice a year for a few hours is enough.  We don't get all our
planning done at the summit (although we do get a lot done), and I think
the same applies here.  You bring up a really great point here, we don't
have a good way for an operator to file a bug against OpenStack (
http://launchpad.net/openstack) that describes a pain point and not a
solution.

So as an operator, I want to be able to file a bug saying 'X is a problem
for me' and not know if its a nova issue or a glance issue etc or know how
to fix it.


>
>
> I personally have a different proposal to Tristan (although I like his)…
> my proposal is that each program should have a session dedicated to
> user/operator needs at the start.  Between the UC, the volunteers to look
> at the survey comments and the user group ambassadors, we should be able to
> put together a set of pain points to be considered for the next release…
> solutions are up to the design teams.
>

I like the general direction this thread is going.


>
>
> Tim
>
>
>
> *From:* Joe Gordon [mailto:joe.gord...@gmail.com]
> *Sent:* 16 December 2013 18:38
> *To:* Tristan Goode
> *Cc:* openstack@lists.openstack.org
>
> *Subject:* Re: [Openstack] Bringing focus to the Operators and Users at
> the next summit
>
>
>
>
>
>
>
> On Sun, Dec 15, 2013 at 10:36 PM, Tristan Goode 
> wrote:
>
> I'm trying to establish a feedback loop "because" we (Operators, Users,
> etc)
> need to better present our actual real world, evidence based Operator,
> User,
>
> and even other input like Sales and Marketing experiences back into the
>
> development teams. Much of this does and will come from the great work of
> the UC, the User surveys, and especially the folks that have volunteered to
> analyse the survey results. I'm hoping to build on the survey analysis and
> collaboratively and constructively focus that to present a blueprint or
> roadmap with a "whole of OpenStack" scope. We can dig deeper into the user
> survey feedback and break beyond the bounds of the limited format of the
> user survey to seed the discussion. For me, the most valuable session in
> Hong Kong was the discussion led by Tim of the user survey. It was however,
> all too short.
>
>
>
> Do you have any examples of what kind of feedback you would like to pass
> on to developers (I was unable to attend Tim's discussion of the user
> survey)?  Also just playing devils advocate here, but why not use our bug
> system to provide feedback?
>
>
>
>
>
> > -Original Message-
> > From: Sean Dague [mailto:s...@dague.net]
> > Sent: Saturday, 14 December 2013 3:02 AM
> > To: openstack@lists.openstack.org
> > Subject: Re: [Openstack] Bringing focus to the Operators and Users at the
> > next
> > summit
> >
> > So not that I don't think this is a worth while thing, because I think it
> > is. But instead
> > of jumping to the solution of a User Day, it might be useful to figure
> out
> > what's
> > attempting to be solved.
> >
> > Is it?
> >
> > 1) get Users together to share best practices among themselves? Because
> > lots of
> > people have learned things, and want to bootstrap others.
> >
> > 2) get Users and Operators together to share best practices among
> > themselves?
> > Because ...
> >
> > 3) get Vendors and Users and Operators together? Because ...
> >
> > 4) get Developers and Users and Operators together? Because 
> >
> > I think if you start with defining the Because ... part, then the needed
> > parties, then

Re: [Openstack] Bringing focus to the Operators and Users at the next summit

2013-12-27 Thread Joe Gordon 
On Dec 27, 2013 4:24 AM, "Tristan Goode"  wrote:
>
> I'm having trouble seeing these great points of insight here other than
it seems to indicate that the design summit format could be improved.
Distilling this down to "We developers are all too busy at the summit, why
don’t you users go get your own thing" suggests that perhaps it's time for
a review of the summit format.
>

I think that's missing a key point, there is much more to this then
evaluating the summit format. The summit is the middle of a long
development dialog not the beginning or the end. Getting more operator
feedback to the developers shouldn't just happen at the summits, it should
be a continuous process just like openstack planning and development. So we
need some way for operators and developers to have a continuous dialog.
Developers communicate today on: IRC, email and launchpad and lastly in
person twice a year at the design summit.

>
>
> After all it does say "users" and "developers" on the summit logo.
>
>
>
>
>
>
>
> From: Mark Collier [mailto:m...@collierclan.net]
> Sent: Tuesday, 24 December 2013 12:30 AM
> To: Sean Dague
>
> Cc: openstack@lists.openstack.org
> Subject: Re: [Openstack] Bringing focus to the Operators and Users at the
next summit
>
>
>
> Thanks Sean. You and Thierry have made great points on this thread that I
think give people more insight into the process and timing required to
really impact the releases.
>
> I've fallen into the trap many times of thinking we can solve any problem
in the world during the 10 days a year we are all together, but in the end
its only 10 days. No matter how you organize them, they don't any get
longer.
>
> So +1 for some activities well before the summit to gather input. I think
Tim's suggestion makes a ton of sense.
>
> IMHO we should also avoid the trap of thinking that for gatherings to be
valuable "everyone has to be there". That's what leads back to thinking the
summit weeks are the answer to everything. As Tim said, it's quite likely
operators are experiencing a lot of the same pain points, so what is needed
is critical mass and action, not every known user in one room
(unrealistic). Perhaps with some online components where operators that
couldn't make a meetup can weigh in (and give a weighted priority to a
list?)
>
> On Dec 23, 2013 6:35 AM, "Sean Dague"  wrote:
>>
>> On 12/22/2013 12:49 PM, rob_hirschf...@dell.com wrote:
>> > I’d like to repeat a suggestion at the Design Summit wrap up – it’s a
>> > bit different, so patience…
>> >
>> >
>> >
>> > My suggestion was to insert a day “break” into the four day Design
>> > Summit for users/operations.  Effectively, we’d have a four day design
>> > summit with Monday+Tuesday  - break for user/ops conf –
>> > Thursday+Friday.  This would allow the developers and PTLs to join in
>> > the conference parts of the summit without needed a distinct event.
>> > The regular non-design conference could be held Tuesday-Thursday so
>> > there’s a specific overlap day when 100% of the community would be
together.
>> >
>> >
>> >
>> > I felt like this allows ideas from the summit to be socialized with
>> > users/operator before we commit to them.  I also felt that it makes the
>> > developers more accessible.  Finally, it creates a break/reflection
from
>> > the intensity of the design.
>> >
>> >
>> >
>> > To recap, 4 day design, 3 day user/ops conference spanning 5 days.
>>
>> Honestly I'd be pretty -1 on that idea. There is a certain momentum that
>> builds inside the design summit sessions that 2 hard context switches
>> like that would really hurt. If you've ever spent time in the Nova track
>> you can see this in spades.
>>
>> I think one of the missing things for folks that don't spend all their
>> time in Design Summit is realizing that DS is really the *middle* of the
>> conversation, not that start of one. I actually think this is where
>> folks new to design summit tend to flail a little be in their sessions.
>> My goals for design summit, and my tracks, were set weeks in advance,
>> and there was very little new here, it was mostly about working through
>> the sticky details on things we largely were already working on, and
>> exposing some of that work to a wider audience which drags in new
>> volunteers. So the User / Ops day at Summit is far too late to impact
>> that release cycle.
>>
>> That interaction needs to come 3+ weeks before Design Summit to be
>> effective on that cycle. Because if it's later than that, it's just too
>> much to digest at a point where the plates are already overflowing. The
>> key developers are already about 200% booked at Summits at this point,
>> which is actually why *more* OpenStack PTLs spoke at LinuxCon NA this
>> year than at OpenStack Summit HK. For instance, I only wandered out side
>> of Design Summit twice, when I was on stage. And I didn't even get a
>> chance to go to any of the public parties, as I was booked every single
>> night at summit - weeks in advance.
>>
>> So I think that all

Re: [Openstack] Bringing focus to the Operators and Users at the next summit

2013-12-27 Thread Joe Gordon 
t to some other time and venue send a
> message to customers who might want to participate, the sure to be less
> attendance would dilute the input of Ops into the DevOps cycle and
> prejudice those of us that can't afford to send people to more events than
> the summits.
>
>
>
> Cheers
>
> Tristan
>
>
>
>
>
>
>
> *From:* jagman4...@gmail.com [mailto:jagman4...@gmail.com] *On Behalf Of *Joe
> Gordon
> *Sent:* Saturday, 28 December 2013 12:37 AM
> *To:* Tristan Goode
> *Cc:* Mark Collier; openstack@lists.openstack.org
>
> *Subject:* Re: [Openstack] Bringing focus to the Operators and Users at
> the next summit
>
>
>
>
> On Dec 27, 2013 4:24 AM, "Tristan Goode"  wrote:
> >
> > I'm having trouble seeing these great points of insight here other than
> it seems to indicate that the design summit format could be improved.
> Distilling this down to "We developers are all too busy at the summit, why
> don’t you users go get your own thing" suggests that perhaps it's time for
> a review of the summit format.
> >
>
> I think that's missing a key point, there is much more to this then
> evaluating the summit format. The summit is the middle of a long
> development dialog not the beginning or the end. Getting more operator
> feedback to the developers shouldn't just happen at the summits, it should
> be a continuous process just like openstack planning and development. So we
> need some way for operators and developers to have a continuous dialog.
> Developers communicate today on: IRC, email and launchpad and lastly in
> person twice a year at the design summit.
>
> >
> >
> > After all it does say "users" and "developers" on the summit logo.
> >
> >
> >
> >
> >
> >
> >
> > From: Mark Collier [mailto:m...@collierclan.net]
> > Sent: Tuesday, 24 December 2013 12:30 AM
> > To: Sean Dague
> >
> > Cc: openstack@lists.openstack.org
> > Subject: Re: [Openstack] Bringing focus to the Operators and Users at
> the next summit
> >
> >
> >
> > Thanks Sean. You and Thierry have made great points on this thread that
> I think give people more insight into the process and timing required to
> really impact the releases.
> >
> > I've fallen into the trap many times of thinking we can solve any
> problem in the world during the 10 days a year we are all together, but in
> the end its only 10 days. No matter how you organize them, they don't any
> get longer.
> >
> > So +1 for some activities well before the summit to gather input. I
> think Tim's suggestion makes a ton of sense.
> >
> > IMHO we should also avoid the trap of thinking that for gatherings to be
> valuable "everyone has to be there". That's what leads back to thinking the
> summit weeks are the answer to everything. As Tim said, it's quite likely
> operators are experiencing a lot of the same pain points, so what is needed
> is critical mass and action, not every known user in one room
> (unrealistic). Perhaps with some online components where operators that
> couldn't make a meetup can weigh in (and give a weighted priority to a
> list?)
> >
> > On Dec 23, 2013 6:35 AM, "Sean Dague"  wrote:
> >>
> >> On 12/22/2013 12:49 PM, rob_hirschf...@dell.com wrote:
> >> > I’d like to repeat a suggestion at the Design Summit wrap up – it’s a
> >> > bit different, so patience…
> >> >
> >> >
> >> >
> >> > My suggestion was to insert a day “break” into the four day Design
> >> > Summit for users/operations.  Effectively, we’d have a four day design
> >> > summit with Monday+Tuesday  - break for user/ops conf –
> >> > Thursday+Friday.  This would allow the developers and PTLs to join in
> >> > the conference parts of the summit without needed a distinct event.
> >> > The regular non-design conference could be held Tuesday-Thursday so
> >> > there’s a specific overlap day when 100% of the community would be
> together.
> >> >
> >> >
> >> >
> >> > I felt like this allows ideas from the summit to be socialized with
> >> > users/operator before we commit to them.  I also felt that it makes
> the
> >> > developers more accessible.  Finally, it creates a break/reflection
> from
> >> > the intensity of the design.
> >> >
> >> >
> >> >
> >> > To recap, 4 day design, 3 day user/ops conference spanning 5 days.
> >>
> >>

Re: [Openstack] Update from DefCore (aka Board's OpenStack Core Definition Committee)

2014-01-09 Thread Joe Gordon 
On Thu, Jan 9, 2014 at 10:48 AM,  wrote:

> Stackers,
>
>
>
> I posted this first on my 
> blog(which is 
> mirrored to Planet OpenStack) and want to make sure that we reach
> a broad audience with the information.  The Board heard very clearly that
> this was an important issues and we’re acting quickly to resolve it in
> transparent and community focused way.
>
>
> OpenStack Core Definition (DefCore) Progress in 6 key areas
>
>
>
> I’m excited to report about the OpenStack Board progress on defining
> OpenStack core .  At the
> Hong Kong summit, Joshua McKenty
>  and I were asked to chair a new standing committee, now known as 
> DefCore,
> to define “OpenStack Core” based on the core 
> principles
>  that we determined over the last 6 months (aka “the 
> spider
> ”).
>
> Joshua and I took on the challenge with gusto and I’m proud to say that
> we’ve already made significant progress against an aggressive timeline to
> have the pilot must-pass tests for Havana defined before the Juno Summit
> in April 2014.
>  It’s important to remember that we’re moving from a project based
> definition of core to test-driven 
> capabilities
>  because this best addresses our interoperability 
> objectives
> .
>
>
>
> In the 8 weeks since the summit, we’ve had seven very productive meetings
> (etherpads for Prep
> , DefCore.1 ,
> DefCore.2 , 
> DefCore.3,
> Criteria 1 and 2 )
> with detailed notes and recorded 
> content.
> Here’s my summary of our results so far:
>
> 1.  *An Aggressive Timeline* for having pilot Havana must-pass tests
> approved by the Juno summit in May 2014.  That drives the schedule backward
> toward a preliminary list in March.  Once we have a pilot list for Havana,
> we expect to have Ice House done +90 days and Juno done at the Paris summit.
>
> 2.  *Test Selection Criteria* a preliminary set of 14 criteria (needs
> a stand alone post) that will be used to quantitatively score the current
> 700+ tests.  We also agreed to use a max 100 point weighting system for the
> criteria.  The weights and score requirement iteratively once we have done
> a first scoring pass.  Our objective is to make must-pass test selection as
> objective and transparent as possible (post with 
> details
> ).
>
> 3.  *Distinction between Capability & Test* is important because we
> recognize that individual tests may validate multiple capabilities and
> individual capabilities may have multiple tests.  Our hope is to present
> the results in terms of capabilities not individual tests.
>
> 4.  *Holding Off on Bylaws Changes* needed to clarify how OpenStack
> manage core definition.  It was widely expected that the DefCore committee
> would have to make changes to the OpenStack bylaws; however, we believe we
> can proceed without rushing changes.  We have an active subcommittee
> preparing changes in advance of the next DefCore cycle.
>
> 5.  *Program vs. Project Definition* efforts are needed to help take
> pressure off requests to have “projects promoted to core status” and how
> the OpenStack trademark is used for projects.  We are trying to clarify
> OpenStack Programs (e.g.: OpenStack™ Compute) carry to the trademark while
> OpenStack Projects (e.g.: Nova and Glace) are members of those programs and
> do not carry the OpenStack trademark directly.  Consequently, we’d expect
> people to say “OpenStack Compute Project Nova” instead of “OpenStack Nova.”
>  This approach addresses several issues that impact DefCore Board
> activities around trademark, core and brand.
>

'OpenStack Compute Project Nova' is pretty wordy and confusing to a layman.


>   6.  *RefStack Development and Use Cases* provide the framework for
> community reporting of test results.  We consider this infrastructure
> critical to getting community input about must-pass tests and also sharing
> interoperability information.  This effort is just beginning and needs help
> from the community.
>
> For all this progress, we are onl

Re: [Openstack] Challenges faced with Openstack keystone v3 API

2014-03-31 Thread Joe Gordon 
On Mon, Mar 31, 2014 at 2:39 AM, Devendra Gupta  wrote:

> Hi,
> We have been doing analysis around keystone v3 api for authenticating with
> openstack components in Havana release but while doing so we are facing
> some issues with the authentication using keytone v3 API .
>
> Below is the list of Components that we are using along with versions:-
> *Compute : v2*
> *Identity : v2.0 & v3*
> *Network : v2*
> *Image : v2*
>
>

>
> Following are the concerns that we have :-
>
> 1. After getting authentication token using API */v3/auth/tokens *and
> supplying userid, password along with project scope , when we try to hit
> Compute's API
> *  v2/58d73fe0ec9c44e7a2127bf8abd60dc2/os-networks* we are getting
> *Internal server error occured : code 500.*
>


Nova doesn't support keystone v3 yet.



>
>
>  Moreover , even if we try to hit other components like Neutron we have
> similar issues . However, when we hit the same API call with keystone v2.0
> generated auth token we are able to get results as desired.
>
> Since keystone is by default enabled to use v3 and v2.0 , the tokens
> generated by v3 should be able to authenticate for othe components like
> nova, neutron , glance which it is not happening as of now.
>
> So is it a configuration issue or keystone v3 version is not yet supported
> by other components.
>
> 2. Can there be a scenario where keystone will be setup with v3 only
> instead of both v2.0 and v3.
>
> Please provide inputs on the above.
>
> Regards,
> Devendra Gupta
>
> ___
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] [nova] running icehouse computes under juno

2015-01-07 Thread Joe Gordon 
On Tue, Jan 6, 2015 at 5:12 PM, Sam Morrison  wrote:

> I’m working on upgrading our nova to Juno.
>
> First I upgrade the control infrastructure, conductor,api,scheduler etc.
> and migrate the DB
> I also set the following on the control hosts
> [upgrade_levels]
> compute=icehouse
>
> I don’t touch the nodes running nova-compute.
>
> Things seem to work however when I start a nova-compute I get the
> following when it registers its service:
>

Are you restarting existing icehouse nova-compute and not juno?

Can you share sanitized copies of your config file as not sure what the
issue is based on the stacktrace alone.


>
> Line in question:
> nova/virt/libvirt/driver.py
> def _set_host_enabled()
> service = service_obj.Service.get_by_compute_host(ctx, CONF.host)
>
>
> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver   File
> "/opt/icehouse/local/lib/python2.7/site-packages/oslo/messaging/rpc/client.py",
> line 155, in call
> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver return
> self.serializer.deserialize_entity(ctxt, result)
> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver   File
> "/opt/nova/nova/rpc.py", line 111, in deserialize_entity
> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver return
> self._base.deserialize_entity(context, entity)
> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver   File
> "/opt/nova/nova/objects/base.py", line 575, in deserialize_entity
> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver entity =
> self._process_object(context, entity)
> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver   File
> "/opt/nova/nova/objects/base.py", line 545, in _process_object
> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver
>  e.kwargs['supported'])
> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver   File
> "/opt/nova/nova/conductor/api.py", line 280, in object_backport
> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver return
> self._manager.object_backport(context, objinst, target_version)
> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver   File
> "/opt/nova/nova/conductor/rpcapi.py", line 435, in object_backport
> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver
>  target_version=target_version)
> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver   File
> "/opt/icehouse/local/lib/python2.7/site-packages/oslo/messaging/rpc/client.py",
> line 155, in call
> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver return
> self.serializer.deserialize_entity(ctxt, result)
> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver   File
> "/opt/nova/nova/rpc.py", line 111, in deserialize_entity
> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver return
> self._base.deserialize_entity(context, entity)
> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver   File
> "/opt/nova/nova/objects/base.py", line 575, in deserialize_entity
> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver entity =
> self._process_object(context, entity)
> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver   File
> "/opt/nova/nova/objects/base.py", line 545, in _process_object
> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver
>  e.kwargs['supported'])
> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver   File
> "/opt/nova/nova/conductor/api.py", line 280, in object_backport
> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver return
> self._manager.object_backport(context, objinst, target_version)
> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver   File
> "/opt/nova/nova/conductor/rpcapi.py", line 435, in object_backport
> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver
>  target_version=target_version)
> …. REPEATED….
> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver   File
> "/opt/icehouse/local/lib/python2.7/site-packages/oslo/messaging/rpc/client.py",
> line 152, in call
> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver
>  retry=self.retry)
> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver   File
> "/opt/icehouse/local/lib/python2.7/site-packages/oslo/messaging/transport.py",
> line 90, in _send
> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver
>  timeout=timeout, retry=retry)
> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver   File
> "/opt/icehouse/local/lib/python2.7/site-packages/oslo/messaging/_drivers/amqpdriver.py",
> line 436, in send
> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver
>  retry=retry)
> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver   File
> "/opt/icehouse/local/lib/python2.7/site-packages/oslo/messaging/_drivers/amqpdriver.py",
> line 422, in _send
> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver
>  retry=retry)
> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver   File
> "/opt/iceho

Re: [Openstack] Feature wish list somewhere? 2 Devs looking to contribute

2015-01-23 Thread Joe Gordon 
On Thu, Jan 22, 2015 at 7:56 PM, Michael Gale 
wrote:

> Hey,
>
> Does anyone know where I could find a feature wishlist? Ideally a list
> of outstanding features or functionality that is wanted. But is currently
> missing from OpenStack and not being worked on or has been started but
> needs a lot of dev help?
>
> I am looking for a way that 2 full time python devs could contribute to
> the project.
>
>
One nice way to get your feet wet is looking at low hanging fruit bugs:

https://bugs.launchpad.net/openstack/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_subscriber=&field.tag=low-hanging-fruit&field.tags_combinator=ANY&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on&search=Search



> Thanks
> Michael
>
>
>
>
> ___
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] OpenStack 2014.2.2 released

2015-02-06 Thread Joe Gordon 
So stable/juno grenade is still broken, meaning projects that stable/juno
branches that  gate on grenade are blocked,

http://logs.openstack.org/02/153502/2/check/check-grenade-dsvm/f1f3e83/logs/grenade.sh.txt.gz#_2015-02-06_10_59_31_200

2015-02-06 10:59:31.200

| pkg_resources.ContextualVersionConflict: (oslo.config 1.4.0
(/usr/local/lib/python2.7/dist-packages),
Requirement.parse('oslo.config>=1.6.0'), set(['tempest-lib']))


On Thu, Feb 5, 2015 at 10:17 AM, Chuck Short 
wrote:

> Hello everyone,
>
> The OpenStack Stable Maintenance team is happy to announce the 2014.2.2
> stable Juno release.  We have been busy reviewing and accepting
> backported bugfixes to the stable/Juno branches according to the criteria
> set at:
>
> https://wiki.openstack.org/wiki/StableBranch
>
> A total of 104 bugs have been fixed across all projects since 2014.1.2.
> These updates to Juno are intended to be low risk with no intentional
> regressions or API changes. The list of bugs, tarballs and other milestone
> information for each project may be found on Launchpad:
>
> https://launchpad.net/ceilometer/juno/2014.2.2
> https://launchpad.net/cinder/juno/2014.2.2
> https://launchpad.net/glance/juno/2014.2.2
> https://launchpad.net/heat/juno/2014.2.2
> https://launchpad.net/horizon/juno/2014.2.2
> https://launchpad.net/keystone/juno/2014.2.2
> https://launchpad.net/neutron/juno/2014.2.2
> https://launchpad.net/nova/juno/2014.2.2
> https://luanchpad.net/sahara/juno/2014.2.2
> https://launchpad.net/trove/juno/2014.2.2
>
> Release notes may be found on the wiki:
>
> https://wiki.openstack.org/wiki/ReleaseNotes/2014.2.2
>
> The freeze on the stable/juno branches will be lifted today as we
> begin working toward 2014.2.3, which will be released on a TBD.
>
> Thanks
> chuck
>
> ___
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack