On Oct 18, 2018, at 11:43 AM, Michał Dulko wrote:
>
> I'm totally supportive for OpenStack Train, but got to say that
> OpenStack Troublesome is a wonderful name as well. :)
Yeah, I’m sure that the marketing people won’t have a problem vetting that
name. :
ompleted, or are we planning on encouraging its use?
-- Ed Leafe
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.o
t to write good, solid code that doesn't encourage
technical debt accumulation. We have no way to prevent bad decisions by others,
but we should never document that such usages are fine.
-- Ed Leafe
signature.asc
Description: Message signed with OpenPGP
__
namespace
and the length. If other service want to be overly clever and try to overload a
trait name, it's up to them to deal with the resulting mess. But in no way
should we *ever* encourage, even tacitly, this approach.
-- Ed Leafe
signature.asc
Description: Message signed wit
ps://git.openstack.org/cgit/openstack/api-sig
[7] http://eavesdrop.openstack.org/#API_Special_Interest_Group
Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meet
On Sep 19, 2018, at 10:25 AM, Chris Dent wrote:
>
> I'd like to nominate Tetsuro Nakamura for membership in the
> placement-core team.
I’m not a core, but if I were, I’d +1 that.
-- Ed Leafe
__
org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg
-- Ed Leafe
__
OpenStack Development Mailing List (not for usa
ement
IRC channel.
-- Ed Leafe
[0] https://etherpad.openstack.org/p/placement-extract-stein-3
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstac
ome of that decision. Revisiting it now would be painful, as Chris
notes, and do nothing to advance the progress we have been making. Let’s focus
on the work in front of us, and not waste time revisiting past decisions.
e I don’t know enough about Open API to
compare them.
-- Ed Leafe
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.
of the filtered directory and a nova directory to get a list
of what has been removed, but that can be somewhat messy. I just want to set
expectations when reviewing the extracted code in gerrit.
-- Ed Leafe
__
Open
hat we need to
> know to do the eventual merging correctly and efficiently.
I’ve re-run the extraction, re-arranged the directories, and cleaned up most of
the import pathing. The code is here: https://github.com/EdLeafe/placement. I
did a forced pus
As there were only 2 nominations for the 2 open seats, elections will not be
needed. Congratulations to Matt Van Winkle and Joseph Sandoval!
-- Ed Leafe
__
OpenStack Development Mailing List (not for usage questions
rn among the Nova core developers is that the consensus
among Placement cores will certainly not align with the needs of Nova. I
personally think that's ridiculous, and, as one of the very opinionated people
involved, a bit insulting. No one wants to see either Nova or Placement to fail.
etwork in the past.
That detail aside, the question is still valid: did the split from working
within the Nova project to working as an independent project have positive or
negative effects? Or both?
-- Ed Leafe
__
OpenS
rse there are political factors; it would be naive to think otherwise.
That’s why I’d like to get input from those people who are not in the middle of
it, and have no political motivation. I’d like this to be a technical
discussion, with as little poli
nful it will be to
extract, and hence the likelihood of that every happening is greatly diminished.
-- Ed Leafe
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-
inate them (with their
permission, of course)! Help make a difference for Operators, Users and the
Community!
-- Ed Leafe
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev
ki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg
-- Ed Leafe
__
OpenStack Development Mailing List (not fo
confirmed by one of the election officials, after verification of the
electorate status of the candidate.
[0] Sorry, southern hemisphere people!
-- Ed Leafe
__
OpenStack Development Mailing List (not for usage questions
] https://tools.ietf.org/html/draft-ietf-httpbis-bcp56bis-06
Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
Open Bugs
https://bugs.launchpa
there was nothing
blocking you that we could help with.
-- Ed Leafe
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubsc
ss!
We have migrated the API-SIG from Launchpad to StoryBoard [0], specifically so
that your group has a place to record stories, tasks, etc. Please feel free to
use this to help coordinated your work.
[0] https://storyboard.open
ut to be the
"wrong" thing that nothing gets done.
-- Ed Leafe
signature.asc
Description: Message signed with OpenPGP
__
OpenStack Development Mailing List (not for usage questions)
Unsubscri
API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg
-- Ed Leafe
__
OpenStack Development Mailing List (not for usage qu
its contributors/cores are
>> from one company, maybe it should be an internal project for that company,
>> and not a community project.
>>
>> -- Ed Leafe
>
> Where was the rule added, though? I am aware of some individual teams
> with the rule, but AFAIK it w
t, it just seems prudent to keep them. If a
project is so small that the majority of its contributors/cores are from one
company, maybe it should be an internal project for that company, and not a
community project.
-- Ed Leafe
is think they can create a more impressive PoC with
another API, the API-SIG will support that.
-- Ed Leafe
signature.asc
Description: Message signed with OpenPGP
__
OpenStack Development Mailing List (not f
very, very rare in my OpenStack experience. Nitpicking, on the other hand, is
much more prevalent, and I welcome these efforts to reduce it.
-- Ed Leafe
signature.asc
Description: Message signed with OpenPGP
__
OpenStack
I would have preferred to fix the whole thing by not storing the
marker in the first place.
-- Ed Leafe
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...
ould want to see.
-- Ed Leafe
__
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
.org/cgit/openstack/api-wg
[7] http://lists.openstack.org/pipermail/openstack-dev/2018-April/129987.html
[8] http://graphql.org/
Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
Open Bugs
https://bugs.launchpa
its API exposes things at an individual table level, requiring the client to
join that information to get the answers they need.
Once that is done, we could examine the results, and use them as the basis for
proceeding with something more comprehensive. Does that sound like a good
approach to
artificially limit what people could use
to control their deployments, but inside of Nova there is a lot of confusion as
to whether anyone is using anything but the included filters.
So - does anyone out there rely on a filter and/or weigher that they wrote
themselves, and maintain outside of
ified sounds pretty sane to me.
-- Ed Leafe
__
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
enstack.org/#/c/554921/
Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg
-- Ed Leafe
__
Open
k on my communication skills. This is what I’ve been saying all
along.
-- Ed Leafe
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?sub
extra directory level in
nova/api/openstack. There is only one Nova API, so the extra ‘openstack’ level
is no longer needed.
-- Ed Leafe
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openst
e 100 hosts, you don’t need to make 100 calls to
Cyborg; only 1.
-- Ed Leafe
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
htt
ed one by one. You can subclass the BaseWeigher (in
nova/weights.py) to weigh all objects at once.
-- Ed Leafe
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@l
t range of times would work for you?
-- Ed Leafe
__
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
e. I've updated the PEP to say 2.7 is completely dead on Jan 1
> 2020." adding "The final release may not literally be on January 1st".
>
> https://www.python.org/dev/peps/pep-0373/ now says
> "2.7 will receive bug
; summaries later :)
When is your meeting? I don’t see it listed on http://eavesdrop.openstack.org.
-- Ed Leafe
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@li
it.openstack.org/cgit/openstack/api-wg
[7] https://twitter.com/anticdent/status/968503362927972353
Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
Open Bugs
https://bugs.launchpa
herpad.openstack.org/p/api-sig-ptg-rocky
[8] https://ethercalc.openstack.org/xja22ghws13i
Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
Open Bugs
https:
On Feb 15, 2018, at 9:43 AM, Steven Dake (stdake) wrote:
>
> The election process I'm certain is very difficult to execute, and as a
> community member, I'd like to thank the election officials for their work.
Having done it once, I can agree! Thanks for making things run s
On Feb 15, 2018, at 2:41 PM, Marcin Juszkiewicz
wrote:
>
>> Second, there will be 2 others from my ppc64le team getting involved
>> in Kolla, Mark Hamzy and Ed Leafe. Ed will be attending PTG and will
>> try to get a chance to meet a few of you there.
>
> Please te
On Feb 12, 2018, at 9:57 AM, Chris Dent wrote:
>
> Tuesday would be best for me as Monday is api-sig day.
Same, for the same reason.
-- Ed Leafe
__
OpenStack Development Mailing List (not for usage que
935
Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg
-- Ed Leafe
__
OpenStack De
suggestion for how to
make your RPC-ish API consistent with other projects that also use an RPC-like
approach to parts of their API.
-- Ed Leafe
__
OpenStack Development Mailing List (not for usage questions
of relying upon the URL to determine
what action to perform.
You might also want to contact the Kong developers to see if there is a way to
work with a RESTful API design.
-- Ed Leafe
[0]
http://eavesdrop.openstack.org/meetings/api_sig/2018/a
ocess disorder in the meantime.
I still don't understand how anyone could do what you have done over these past
two years and not a) had a stress-induced heart attack or b) gotten divorced.
Thanks for the hard work!
-- Ed Leafe
___
genda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg
-- Ed Leafe
__
OpenStack Development
ew paradigm.
-- Ed Leafe
signature.asc
Description: Message signed with OpenPGP
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsub
tion aren’t real. I’m just pointing
out that there are downsides to stretching things out.
-- Ed Leafe
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.or
On Dec 14, 2017, at 3:01 AM, Thomas Goirand wrote:
>
> As a package maintainer who no longer can follow the high pace, I very
> much support this change.
So you’re saying that you would be ignoring any intermediate releases?
--
ere we're at is a tightly coupled mess, what I don't agree
> with is that the answer is to keep shipping the mess.
I agree 100% with that sentiment. However, *until* we achieve something close
to that, we have to continue to ship “this mess”. Taking a mess and
that we're all still working together well.
[0] https://blog.leafe.com/on_swift/
-- Ed Leafe
signature.asc
Description: Message signed with OpenPGP
__
OpenStack Development Mailing List (not for usage questions)
Unsub
there is no distraction by the corporate
marketing machines, and we can focus on getting shit done.
My question is: if we only have a release once a year, why do we need two
Summits a year?
-- Ed Leafe
signature.asc
Descriptio
oes it mean if Nova has
some new stuff, but it requires a new release from Cinder in order to use it,
and Cinder hasn't yet released the necessary updates? Talking about releasing
projects on a monthly-tagged basis just dumps the problem of determining what
works with the rest of the code
year for some improvements.
Maybe it’s just the dev in me, but I prefer shorter cycles (CD, anyone?).
-- Ed Leafe
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack
>
> https://doodle.com/poll/bec9gfff38zvh3ud
>
> If you’re interested in attending API-SIG meetings, please fill out the form
> at that URL with your preferences. I’ll summarize the results at the next
> API-SIG meeting.
>
>
> -- Ed Leafe
>
>
>
>
>
On Dec 7, 2017, at 11:22 AM, Ed Leafe wrote:
> That brought up another issue: the current meeting time for the API-SIG is
> 1600UTC, which is not very convenient for APAC contributors. Gilles is in
> Australia, and so it was the middle of the night for him! As one of the goals
>
8] https://review.openstack.org/#/c/524467/
Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
Open Bugs
https://bugs.launchpa
k/api-wg,n,z
[4] https://wiki.openstack.org/wiki/API_SIG
Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
Open Bugs
https://bugs.launchpad.net/openstack-api-
On Nov 2, 2017, at 4:17 AM, Dmitry Tantsur wrote:
>
> The recording of the call is https://bluejeans.com/s/K3wZZ
Ugh: "To watch the video, you need Adobe Flash Player 10.1 or higher"
-- Ed Leafe
machine
with 100 GPUs - ok, I know that's not realistic, but it illustrates my point.
Each hardware combination is a separate resource class. If your workload
requires 2 GPUs and SSD, there are a finite number of hardware combinations
available. You pick
ind the answers for the people I am considering voting for.
-- Ed Leafe
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://list
e questions this time, and the answers
(and non-answers) strongly influenced my vote. So I would rather see a shorter
nomination period and a longer “campaign” period in the future.
-- Ed Leafe
__
OpenStack Development M
genda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg
-- Ed Leafe
__
OpenStack
for a large variety
> of somebodies.
I wish all candidates, not just TC candidates, got follow-up questions like
this. Bravo, Zane!
-- Ed Leafe
__
OpenStack Development Mailing List (not for usage questions)
Un
m administration related tasks.
Thanks for the answer, and I definitely agree. But I don't feel that you
answered the important part: what would you have wanted the TC to do about this?
-- Ed Leafe
signature.asc
Description
In the past year or so, has there been anything that made you think “I wish the
TC would do something about that!” ? If so, what was it, and what would you
have wanted the TC to do about it?
-- Ed Leafe
__
OpenStack
e change to the previous design.
-- Ed Leafe
signature.asc
Description: Message signed with OpenPGP
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subj
Open Bugs
https://bugs.launchpad.net/openstack-api-wg
-- Ed Leafe
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.ope
e
of the other resource class available, and would include that if another
request for that class is received, which would then fail as the node is
already in use.
-- Ed Leafe
__
OpenStack Development Mailing List (
ould go for the
first. And I’m not sure that we will be able to get the “inherited” traits used
in the second model implemented any time soon.
-- Ed Leafe
__
OpenStack Development Mailing List (not for usage questio
s what I thought, too, but apparently [0] we need both in Pike. The
zeroing out can’t happen until Queens.
[0] https://review.openstack.org/#/c/484949/2/nova/virt/ironic/driver.py@471
-- Ed Leafe
__
OpenStack Develop
/487504/
Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_wg/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg
-- Ed Leafe
signature.asc
Descriptio
e people as to what OpenStack is. But that
doesn’t require any of the other projects be stopped or in any way discouraged.
-- Ed Leafe
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-
utions in IaaS, PaaS, and SaaS. And Azure PaaS platform services can help
you be more productive and increase your ROI according to this Forrester Total
Economic Impact study.”
So I don’t think that this distincti
wiki/Meetings/API-WG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_wg/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg
-- Ed Leafe
signature.asc
Description: Message signed with OpenPGP
__
be errors. You are calling the API to set a particular
condition. The result of that call is that the service is in that condition.
That should be a 2xx, most likely a 204. So yeah, it should be idempotent.
-- Ed Leafe
signature.
eplace it with Glare, are you saying
that nothing would break? Operators, users, scripts, SDKs, etc., would all work
unchanged?
-- Ed Leafe
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: ope
Nova, so I'm expecting responses that "of course you
don't care", or "OpenStack is people, and you're hurting our feelings!". So
flame away!
-- Ed Leafe
signature.asc
Description: Message signed with OpenPGP
e the information to a)
select the best fit and then b) claim it with the specific uuid. Same for all
the other nested/shared devices.
I don't mean to belabor this, but to my mind this seems a lot less disruptive
to the existing code.
-- Ed Leafe
signature.asc
Description: Message si
gic are the
placement engine, which knows about these relationships already, or the compute
service itself, which has to handle the management of these complex virtualized
resources.
I don't know the answer. I'm hoping that we can have a discussion that might
uncover a cle
62814/
[5] https://review.openstack.org/#/c/446138/
Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_wg/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg
-- Ed Leafe
sign
is "flavors", but the goal is to have a single flavor for
each Ironic machine type, rather than the current state of flavors pretending
that an Ironic node is a VM with certain RAM/CPU/disk quantities.
-- Ed Leafe
signature.as
ut what resources they got
> instead of just the performance. We also create a mogan horizon plugin which
> adds separated baremetal servers panel[1].
So Mogan does not use the placement service for tracking resources?
-- Ed Leafe
signature.asc
Descript
teract with the TC, as it follows the same naming
convention as #openstack-nova, #openstack-ironic, etc.
-- Ed Leafe
signature.asc
Description: Message signed with OpenPGP
__
OpenStack Development Mailing List (not for usage q
end up
> dedicating to open discussion in the meetings does not encourage people
> to load large topics of discussions in it.
Simple: *start* the meeting with Open Discussion.
-- Ed Leafe
signature.asc
Description:
-WG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_wg/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg
-- Ed Leafe
signature.asc
Description: Message signed with OpenPGP
__
OpenStack Developme
interfaces among the various projects to create a
platform that solutions can be built upon.
-- Ed Leafe
signature.asc
Description: Message signed with OpenPGP
__
OpenStack Development Mailing List (not fo
overy of the Higgs boson, and I'm sure that someday it will
enable technologies that haven't yet been dreamed up. Being able to look back
someday and say "I helped to build that" will be pretty satisfying.
--
ceed at it or not (i swear
> i'm not a manager).
Very good point. In my case, I presented the goal, knowing that at best I might
be able to nudge the OpenStack world a bit closer in that direction.
-- Ed Leafe
t it. Duplicated effort? Solving the same or
a similar problem as another project? Those things shouldn't matter (outside of
the IaaS core projects). Teams should be free to decide if working with another
team is the best approach, or going it alone, for example.
-- Ed Leafe
hierry usually
lets people speak in order of "raising their hand". This reduces cross-talk and
lets everyone get their turn to state what's on their mind. Normally, though,
it is a bit of an acquired skill to be able to follow along.
-- Ed Leafe
s. There will be winners,
and there will be losers, and that's not only OK, it's how it should be.
-- Ed Leafe
signature.asc
Description: Message signed with OpenPGP
__
OpenStack Developme
Hello! I am once again announcing my candidacy for a position on the OpenStack
Technical Committee.
For those who do not know me, I'm easy to find. My name is Ed Leafe; I'm
'edleafe' on IRC, and @edleafe on Twitter. I have been involved with OpenStack
since the very b
1 - 100 of 322 matches
Mail list logo
