On 05/30/2016 06:25 AM, Kashyap Chamarthy wrote:
> On Thu, May 26, 2016 at 10:55:47AM -0400, Sean Dague wrote:
>> On 05/26/2016 05:38 AM, Kashyap Chamarthy wrote:
>>> On Wed, May 25, 2016 at 05:42:04PM +0200, Kashyap Chamarthy wrote:
>>>
>>> [...]
>>&g
ure_delete turned off for volumes for the same
reason, it just adds a ton of delay that impacts a lot of other
unrelated code.
So if there is a flag to just disable it, I think that's fine.
Especially given the fake ironic is qemu guests right? So kill and
reboot should give you a fresh one.
Just make
d only
really use procedural -2s during freeze windows). Feel free to modify
accordingly.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-re
On 05/24/2016 01:59 PM, Sean Dague wrote:
> So, we have a number of open questions:
>
> * Have our cloud providers standardized enough that we might get away
> without this custom cpu model? (Have some of them done it and only use
> those for multinode?)
This is definitely
retty soon upstream libvirt.
Which is good... I wonder how long we'll be waiting for that back in our
distro packages though.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailin
-api-ref/. There is a basic
documentation for the stanzas there and how they are expected to be
used. Contributions welcomed in making those better.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development
ll in the bag I don't want to take the energy and care to make sure we
do a pivot on test strategy to something completely new in a way that is
easy for everyone to contribute to and review.
I feel like we have a good sandbox for this in the placement API, and we
can evaluate at end of cycle for next s
on #4. Are we going to be building a
set of data plane services that can't be in python? If Swift wasn't the
leading
example here would we be having the conversation at all?
-Sean
--
Sean Dague
http://dague.net
___
_TENANT_NAME to support cli tools." ' or make some different info
> for different arguments, such as:
> echo "WARNING: setting legacy
> OS_TENANT_NAME=$OS_PROJECT_NAME to support cli tools."
>
> what do you think?
I think that's a good sugg
s there some representation of the logger that the messaging code can
> use on the other side to reconstruct the logger?
Right, the serialization of the context makes this something I'd rather
avoid. While in the past I've argued for adding more to c
ature around setting libvirt xml
to be able to test live migration in our clouds?
* Other options?
* Do we give up and go herd goats?
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not
d so
the base images are immutable, and stray processes at least have to try
harder to change the data.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questio
ject that is working on that space -
http://docs.openstack.org/developer/searchlight/.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ..
needs, put that into a Keystone backend.
Most of the oslo libraries require other oslo libraries, which is fine.
They aren't trying to solve the general purpose case of logging or
configuration or db access. They are trying to solve a specific set of
patterns that are applicable to OpenStack projec
d time
That should make proposing these kinds of additions easier for folks,
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...
On 05/19/2016 10:37 AM, Hayes, Graham wrote:
> On 18/05/2016 20:12, Sean Dague wrote:
>> On 05/18/2016 02:42 PM, Hayes, Graham wrote:
>>> I was moving Designate to the os-api-ref extension, and I spotted
>>> something I thought we could do to improve the readability
On 05/18/2016 11:56 AM, Dean Troyer wrote:
> On Wed, May 18, 2016 at 10:20 AM, Sean Dague <s...@dague.net
> <mailto:s...@dague.net>> wrote:
>
> nova-net is now deprecated - https://review.openstack.org/#/c/310539/
>
>
> Woot! Now to make it not-the-def
t there instead of elsewhere.
I kind of wonder if:
.. rest_status_code:: 400, 401, 403, 405, 409, 500
- 409: The fizbuz is locked and can't be updated until unlock is
performed.
And generic messages for everything without the extra entry would work.
-Sean
--
Sean Dague
http://dague.net
et it rolling.
Feedback on this idea would be welcomed. We're going to deprecate the
proxy APIs regardless, however disable_deprecated_apis is it's own idea
and consequences, and we really want feedback before pushing forward on
this.
-Sean
--
Sea
ttps://review.openstack.org/#/c/318019/ which passes
with all your data.
Thanks for digging in so early in this process.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for u
worth
engaging the OpenAPI upstream community. Our current implementation is
pretty OpenStack specific, but the concept would apply to any open
source project with a REST API that is CDed at different rates by
different deployers.
-Sean
--
Sean Dague
http://dague.net
_
On 05/16/2016 03:18 PM, Sean Dague wrote:
> On 05/09/2016 08:23 AM, Sean Dague wrote:
>> There is a lot of work to be done to get the api-ref into a final state.
>>
>> Review / fix existing patches -
>> https://review.openstack.org/#/q/project:openstack/nova+file:a
On 05/09/2016 08:23 AM, Sean Dague wrote:
> There is a lot of work to be done to get the api-ref into a final state.
>
> Review / fix existing patches -
> https://review.openstack.org/#/q/project:openstack/nova+file:api-ref+status:open
> shows patches not yet merged. Ple
going to play a little fast and loose during this
introduction to keep folks going as fast as possible.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions
On 05/09/2016 08:23 AM, Sean Dague wrote:
There is a lot of work to be done to get the api-ref into a final state.
Review / fix existing patches -
https://review.openstack.org/#/q/project:openstack/nova+file:api-ref+status:open
shows patches not yet merged. Please review them
eface portion of the release notes,
as that's probably one of the most important bits of info to people.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
On 05/09/2016 08:23 AM, Sean Dague wrote:
> There is a lot of work to be done to get the api-ref into a final state.
>
> Review / fix existing patches -
> https://review.openstack.org/#/q/project:openstack/nova+file:api-ref+status:open
> shows patches not yet merged. Ple
|target) work for you all here?
The above patch to grenade will be merged soon to unblock ironic's
upgrade efforts. I'm happy to carve off another interface here if this
is the root cause of the failure, though I'm not hugely sure why that
would be. Please let me know.
-Sean
--
Sean Dague
http
And they'll all get fair
warning for the month prior to the big red switch.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.opens
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
Sean Dague
http://dague.
create as well.
Does ironic's ovs setup need to happen after the neutron create phase
here, or does it just need to happen before nova?
Does ironic need to overwrite the $net_id that gets passed to Nova later?
-Sean
--
Sean Dague
http://dague.net
___
On 05/11/2016 09:06 AM, Sean Dague wrote:
> On 05/09/2016 08:23 AM, Sean Dague wrote:
>> There is a lot of work to be done to get the api-ref into a final state.
>>
>> Review / fix existing patches -
>> https://review.openstack.org/#/q/project:openstack/nova+file:a
- pre-install, install, post-config, extra each of these calls
currently happen? And why they couldn't just be done by a plugin in said
phase.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development M
On 05/11/2016 01:51 PM, Jeremy Stanley wrote:
> On 2016-05-11 10:04:26 -0400 (-0400), Sean Dague wrote:
> [...]
>> Before deciding that it's unsurmountable, maybe giving delete
>> permissions to a larger set of contributors might be a good idea.
> [...]
>
> I have no o
omething in the space which is:
* new contributors can directly modify without having to ask permission
* supports rich markup (including images)
* is easy to revert to previous save point if we find something has gone
wrong
A wiki definitely hits these points. Oth
On 05/09/2016 08:23 AM, Sean Dague wrote:
> There is a lot of work to be done to get the api-ref into a final state.
>
> Review / fix existing patches -
> https://review.openstack.org/#/q/project:openstack/nova+file:api-ref+status:open
> shows patches not yet merged. Ple
,
u'api-ref/source/servers-action-crash-dump.inc']
- https://review.openstack.org/314629 -
[u'api-ref/source/servers-action-shelve.inc']
I've got some code to generate this, but it's a bit of a mess with hard
coded gerrit id/pass. I'll get it cleaned up and published by end of day
(hopefully).
On 05/09/2016 08:23 AM, Sean Dague wrote:
> There is a lot of work to be done to get the api-ref into a final state.
>
> Review / fix existing patches -
> https://review.openstack.org/#/q/project:openstack/nova+file:api-ref+status:open
> shows patches not yet merged. Ple
t;
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/list
for others to
consume / contribute
* Cinder, Ironic, and Keystone ready to get started on similar conversion
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev
times it's easiest to link to things there
by permalink. I will often use https://github.com/sshaw/git-link to
build me such links if I've got the code down locally.
At worse, I'll link the file and say L### in IRC to just be specific.
It's not quite the same a
the wiki (which has the
value of being google indexed).
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstac
.
Thanks so far to our content contributors: Ronald Bradford, jichenjc,
Alex Xu, Sean Dague
And our reviewers: Alex Xu, Sean Dague
There is a ton of work to be done here, would love to have more
contributors dive in.
-Sean
--
Sean Dague
http://dague.net
able to see the progress as we go (it's
updated hourly).
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.opens
.com/openstack/nova/blob/8a93fd13786358f882a53e0bf104eeed23541465/nova/api/openstack/compute/quota_sets.py#L107
And needs to function with what we have at hand, which is a project_id
and a nova.context.
-Sean
--
Sean Dague
http://dague.net
__
sk as anything else. Can
OSC handle this? Should it handle it from a best practices perspective?
How are commands exposed / hidden based on user permissions? The fact
that we're going to need a service library mean that a dedicated admin
On 02/24/2016 07:48 AM, Sean Dague wrote:
> We have a specific bug around aggregrate metadata setting in Nova which
> exposes a larger issue with our mysql schema.
> https://bugs.launchpad.net/nova/+bug/1538011
>
> On mysql the following will explode with a 500:
>
>> no
e these the right point people for each driver?
I'll figure out a way to get this on a stable URL at some point (so that
owners can be swapped out), but for now I wanted to just get something
out for people to ponder.
-Sean
--
Sean Dague
http://dague.net
_
On 04/29/2016 10:28 AM, Daniel P. Berrange wrote:
> On Fri, Apr 29, 2016 at 10:13:42AM -0500, Sean Dague wrote:
>> We've just landed the libvirt min to bump us up to 1.2.1 required. It's
>> probably a good time consider the appropriate bump for Otaca.
>>
>>
MIN_LIBVIRT_VERSION to 1.2.8. This will mean
that NUMA support in libvirt (excepting the blacklists) and huge page
support is assumed on x86_64.
And it keeps the ball moving forward.
Objections?
-Sean
--
Sean Dague
http://dague.net
signature.asc
Description: OpenPGP digital signature
ank Mark for this contribution to our community. I
know that I had interactions with folks at these events that I probably
wouldn't have otherwise, that led to understanding different parts of
our project space and culture.
-Sean
--
Sean Dague
http://dague.net
___
of truth, and
get out of date because there is no enforcement matching with the code
itself.
We rejected the giant tracking etherpad this time for that reason.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Developmen
,
then will try to finish it all up with a virtual doc sprint a couple
weeks after summit.
Thanks again to everyone that's been helping we've already merged a ton
of good fixes here -
https://review.openstack.org/#/q/status:merged+topic:bp/api-ref-in-rst
-Sean
--
Sean Dague
http://dague.net
riority.
All the statements here of "use Lang Foo", "use Library X instead" are
pretty shoot from the hip with no actual data. Yes, there are
fundamental issues with python module loading. These are problems that
can be solved if people are willing to do the ha
d).
-Sean
--
Sean Dague
http://dague.net
signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?s
On 04/19/2016 12:05 PM, James E. Blair wrote:
> Sean Dague <s...@dague.net> writes:
>
>> Yes, that would let you see the results of an individual experimental
>> run that is complete before they all return and post to the change. Once
>> they are all done, they are l
nd smoothly transition to neutron. But with over
90% neutron, assuming someone is writing to the nova-network API and not
realizing it's the odd ball, I think is the wrong assumption.
The APIs that work, they are what they are, but we should not make any
more wo
us on ways in
which we can aggressively deprecate them. But figured it was worth
discussion first. Flame away!
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
U
efinitely an open question, especially as it
doesn't fit into the security stream and tools that distros have built
over the last couple of decades.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Developm
On 04/18/2016 12:18 PM, James E. Blair wrote:
> Sean Dague <s...@dague.net> writes:
>
>> On 04/18/2016 11:22 AM, James E. Blair wrote:
>>> Sean Dague <s...@dague.net> writes:
>>>
>>>> Bummer. This gets used a to figure out the state of thing
On 04/18/2016 11:22 AM, James E. Blair wrote:
> Sean Dague <s...@dague.net> writes:
>
>> Bummer. This gets used a to figure out the state of things given that
>> zuul links to the console even after the job is complete. Changing that
>> to the log server link
de. Thanks folks.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.o
On 04/18/2016 08:22 AM, Chris Dent wrote:
> On Mon, 18 Apr 2016, Sean Dague wrote:
>
>> So if you have strong feelings and ideas, why not get them out in email
>> now? That will help in the framing of the conversation.
>
> I won't be at summit and I feel pretty stron
ave to include a
community conversation beyond just the DS session.
So if you have strong feelings and ideas, why not get them out in email
now? That will help in the framing of the conversation.
-Sean
--
Sean Dague
http://dague.net
sci-advisories/lJfvDs5s6bk/4dRqSc4pHgAJ
Bummer. This gets used a to figure out the state of things given that
zuul links to the console even after the job is complete. Changing that
to the log server link would mitigate the blind spot.
-Sean
--
Sean Dague
http://dague.net
_
On 04/15/2016 10:42 AM, Jay Pipes wrote:
> On 04/01/2016 06:45 AM, Sean Dague wrote:
>> #2 - move discover major version back to glanceclient -
>> https://github.com/openstack/nova/blob/3cdaa30566c17a2add5d9163a0693c97dc1d065b/nova/image/glance.py#L108
>>
>>
>> I d
g, could be more of a small post-event open brainstorming
>> for those who would still be around.
>
> This sounds reasonable to me! Would be happy to join such session.
I already have family vacation planned starti
that you have updated
your etherpad before the summit gets started.
Thanks much,
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ
ke Andrey core by the end of
> the week.
>
> [1]
> https://review.openstack.org/#/q/owner:akurilin%2540mirantis.com+project:openstack/python-novaclient
>
> [2] http://stackalytics.com/report/contribution/pyth
On 04/14/2016 05:03 AM, Markus Zoeller wrote:
>> From: Sean Dague <s...@dague.net>
>> To: openstack-dev@lists.openstack.org
>> Date: 04/13/2016 05:08 PM
>> Subject: [openstack-dev] [nova] Nova API doc import, and next steps
>>
>> I think we've gotten t
et updated. That's the issue Steve talked
> about.
>
> The workflow could be, at every new cycle:
> * create a new "release folder" (Newton, Ocata, ...)
> * copy the "setup folders" (minimum-setup, ...) to the new folder
> * clean up the &q
just
takes some time.
I'd like to get the base patches landed in the next day or so so that we
can start chugging through these fixes pre summit, and do a virtual doc
sprint post summit to push through to completion.
-Sean
--
Sean Dague
http:/
On 04/12/2016 03:37 PM, Matt Riedemann wrote:
>
>
> On 4/1/2016 8:45 AM, Sean Dague wrote:
>> The glance v2 work is currently blocked as there is no active spec,
>> would be great if someone from the glance team could get that rolling
>> again.
>>
>> I s
rd any offers from
> companies to host yet. If no one brings it up by the summit, I'll see if
> hosting in Rochester, MN at the IBM site is a possibility.
>
> [1] http://releases.openstack.org/newton/schedule.html
Personal preference is R-11, which is about when it was the last go a
r newer
features. So we solved the discovery / ask for up front, and now there
is a standard mechanism (through a single monotonic value) of providing
for and asking for the new and better API. And works mostly the same
between the 4 services that have now implemented
e primary resource the request was acting on. Or could even
just build some custom loggers Nova side to inject the instance when we
have it.
I'm not sure why oslo.context is an issue though. That's mostly about
putting in the common information about the identity of the requester
into the stream.
nse
> code (as would be the case here -- changing from a 202 to a 400 when
> name is attempted to be changed) then it doesn't need a microversion.
>
> Sean, am I remembering that correctly?
No, in Nova land a 2xx -> 4xx would use a microversion. These sorts of
things actually break pe
ll now. But a lot of
leaked in.
I think Sean Collins' plan is a good one.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-
you can't get to for
various conflicting reasons, consider getting the conversation going
early on the mailing list to get your feedback out there.
Thanks again all, and looking forward to seeing you in Austin.
-Sean
--
Sean Dague
http://dague
ould be a jira ticket, or a REST url for some other
service. This would actually be much like how we handle images in Nova,
with a url to glance to find more info.
-Sean
--
Sean Dague
http://dague.net
__
OpenStac
n entirely reasonable add for the flavors GET call.
It's an API add, so would need a spec, but it's fundamentally pretty
easy and probably not very controversial.
-Sean
--
Sean Dague
http://dague.net
__
OpenS
end networks).
It's not super clear how you deprecate and remove these things without
breaking a lot of people, as a lot of the libraries implement the nova
image resources -
https://github.com/fog/fog-openstack/blob/master/lib/fog/openstack/compute.rb
-Sean
-
e time to
make any of their tooling not assume these flavors by name will be
there, or to inject them yourself if you are sure you need them (as was
done in the devstack case).
-Sean
--
Sean Dague
http://dague.net
eview.openstack.org/#/c/290907/
> [3]
> http://docs.openstack.org/developer/keystonemiddleware/api/keystonemiddleware.auth_token.html#what-auth-token-adds-to-the-request-for-use-by-the-openstack-service
> [4] https://review.openstack.org/#/c/274186/
>
>
>
>
>
>
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo
ron-legacy is the patch I would most expect to have that kind
of side effects.
If breaks happen, please let us know. The response is mostly going to be
'please update your plugins' unless there turns out to be a really bad
issue.
-Sean
--
Sean Dague
http://dague.
On 04/01/2016 10:35 AM, Monty Taylor wrote:
> On 04/01/2016 09:16 AM, Sean Dague wrote:
>> On 04/01/2016 10:08 AM, Monty Taylor wrote:
>>> On 04/01/2016 08:45 AM, Sean Dague wrote:
>>>> The glance v2 work is currently blocked as there is no active spec,
>&
On 04/01/2016 10:08 AM, Monty Taylor wrote:
> On 04/01/2016 08:45 AM, Sean Dague wrote:
>> The glance v2 work is currently blocked as there is no active spec,
>> would be great if someone from the glance team could get that rolling
>> again.
>>
>> I started
ace.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listi
ld work on single interface machines, that would be
great.
The current defaults in devstack are mostly there for legacy reasons
(and because they work everywhere), and for activation energy to getting
a new robust work everywhe
on process, and we have a bit more flexibility in rooms in
Austin than we had in Tokyo.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstac
On 03/31/2016 09:43 AM, Jim Rollenhagen wrote:
> On Thu, Mar 31, 2016 at 08:43:29AM -0400, Sean Dague wrote:
>> Some more details on progress, because this is getting closer every day.
>>
>> There is now an api-ref target on the Nova project. The entire work in
>> progr
deleting the 2.0 legacy
code. The v2.1 on v2.0 compat layer would still be there.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openst
6 2:42 PM, Andrew Laski wrote:
>>>>>
>>>>> On Wed, Mar 30, 2016, at 03:26 PM, Sean Dague wrote:
>>>>>> During the Nova API meeting we had some conversations about priorities,
>>>>>> but this feels like the thing where a mailing list con
source (and we could do a local link
for the few nova net folks) might be more appropriate.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-
empest). There are details on the way Tempest works against all
versions of OpenStack that mean that what is in Tempest is really a
baseline set of tests, plus some tests which test integration
functionality at part
he meeting, plus some of my own thoughts. Please chime in on any
of this. It would be good to be of general agreement pre summit, so we
could focus conversation there more on the hows for getting things done.
-Sean
--
Sean Dague
http://dague.net
signature.as
A gentle reminder that we're continuing to collect suggestions in the
etherpad for the remainder of the week. As of this email there are '8'
suggestions so far. We look forward to many more over the course of the
week.
Thanks again,
-Sean
On 03/23/2016 07:02 AM, Sean Dague wrote
the cycle.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi
not completely giving up on Swagger, we're also
> recognizing the engineering effort to maintain and sustain those efforts
> isn't going to magically appear.
>
> Sean Dague has put together a proof-of-concept with Compute servers
> reference documentation to use Sphinx, RST, pa
401 - 500 of 1956 matches
Mail list logo
