at may address a big chunk of my reservations about
being able to maintain consistency and user experience in a fully
split-OSC world.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List
ometimes a painful one...although wheels were just becoming a
thing when I last tried to bundle OSC into a py2exe-style thing so the
pains of things like OpenSSL may be fewer now.
dt
--
Dean Troyer
dtro...@gmail.com
_
e-write and update at
their own tempo. Dang, did I just deconstruct my project?
One thing I don't like about that is we just replace N client libs
with N (or more) plugins now and the number of things a user must
install doesn't go do
and more interoperable between cloud deployments, to
correctly handle when admin/policy refuses to do something and let the
user sort it out as necessary.
[0]
https://docs.openstack.org/python-openstackclient/latest/contributor/plugins.html#adoption
[1]
https://docs.openstack.org/python-opensta
ple of reports from some of our StarlingX
contributors that access to Freenode IRC works from our (Intel) sites
but not from home. I am not going to speculate as to the cause, it
clearly is not open access, but also not totally closed off.
dt
--
Dean Troyer
dtr
On Fri, Aug 10, 2018 at 7:06 AM, Monty Taylor wrote:
> I'd like to propose removing Brian Curtin, Clint Byrum, David Simard, and
> Ricardo Cruz.
>
> Thoughts/concerns?
Reluctant +1, thanks guys for all the hard work!
dt
--
Dean Troyer
that is all you need
from it those bits could easily go somewhere in osc or osc-lib if you
don't also need them elsewhere.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage quest
that is all you need
from it those bits could easily go somewhere in osc or osc-lib if you
don't also need them elsewhere.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage quest
https://etherpad.openstack.org/p/osc-included_image_signing
[1] https://storyboard.openstack.org/?#!/story/2002128
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: opens
has taken it to a
place where that should now be a possibility. I am willing to find
out that doing so is a good idea. :)
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage question
core
authentication logic, that was long ago pulled out of the keystone
client package.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-r
, I agree, we have said that sort of thing all along: "don't
fork". Many have had to learn that lesson the hard way. This is
another opportunity to show _why_ it can be a bad idea.
dt
--
Dean Troyer
dtro...@gmail.com
___
ick on the conclusions there.
Even after some discussions yesterday it is not clear to me exactly
the right phrasing. I understand that the intention is to become an
incubated edge project, I do not know at what point StarlingX nor
Airship exac
e beginning at least it will be. We have prioritized lists for
where we want to start. Once I get the list and commits cleaned up
everyone can look at them and weigh in on our starting point.
dt
--
Dean Troyer
dtro...@gmail.com
__
figure out how to handle those in the long term.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org
and released. Understanding (some) business decisions
are not one of my strengths.
I will say that my opinion from working with WRS for a few months is
they do truly want to form a community around StarlingX and will be
moving their ongoing Titanium development th
a lot of work to digest before we could even consider that. Is
that the official capacity you are talking about?
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscri
stx-faq
[2] Honestly I don't think that hosting a repo of patches to OpenStack
projects is any different than hosting the repo itself. Also, anyone
remember Qmail? :)
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Developme
have with Neutron,
since SDK isn't 1.0 we may have to play catch-up and maintain multiple
SDK release compatibilities (which has happened at least twice).
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development
t we do not use tag aggressively.
> If Dean is okay, I believe we can migrate to storyboard.
I am all in favor of migrating OSC to use to Storyboard, however I am
totally unable to give it any time in the near future. If Akhiro or
anyone else wants to take on that task, you will have my sup
bclassing network.common.NetworkAndComputeCommand to
leverage that work.
dt
[0] I can't take credit for this, rtheis, amotoki and others worked
this out very nicely.
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Developmen
assumptions out of client-side stuff is the biggest reason OSC NEEDS
to get changed over to the SDK, like, 2 years ago. Then I'll not give
a rats ass about the legacy python client libs.
dt
--
Dean Troyer
dtro...@gmail.com
riends are on the hook to
maintain the compatibility and their patches are (mostly?) accepted.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@l
k
regarding "MTU" in Network commands.
These are not hard rules, but strong guidelines that can and should be
interpreted in the context that they will be applied. And in the end,
the result should be one that
using something to qualify it. The use of --zone in the Compute
commands pre-dates the existence of Designate by at least a coupe of
years. Also, the Network commands use "--dns-*" to refer to anything
specifically DNS related, so for consistency, "--dns-zone" is a better
fit.
> have all commands using one syntax?
This is the sort of thing that should be addressed in the long-overdue
OSC 4 release where we will make small breaking changes like this.
Of course, the old option will be properly deprecated and silently
su
only a
problem the three largest and tightly-coupled projects? In the
current environment I do not see any of our corporate sponsors
stepping up to un-couple those three, but for the rest it seems like
Doug's suggestion goes a long way toward addressing problems being
brought up here.
dt
--
ecifying an image to give me the same
thing it did on the initial build. I suppose it would depend if
shelve/unshelve is supposed to me transparent like Andrew mentioned.
I would assume it would be without reading differently.
dt
--
D
On Thu, Nov 30, 2017 at 8:00 AM, Monty Taylor wrote:
> So let's add them to the core team, yeah?
+1
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Uns
ee to take it over if you want to finish it
up before then.
dt
[0] https://review.openstack.org/#/c/515209/
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscrib
dels too, if I lose my grandfathered-in pricing by being forced
to recreate I amy be unhappy.
> Sylvain's spec in #1 above, maybe we don't have this problem going forward
> since you couldn't remove/delete an AZ when there are even shelved of
On Tue, Oct 10, 2017 at 1:15 PM, Andrea Frittoli
wrote:
> - we will treat +1 from infra-core members on devstack changes in the
> ansible bits as +2
> - add clarkb to devstack-core, since he's quite aware of the the devstack
> codebase
+2 on both of these proposals!
dt
--
so much better with your contributions and
OpenStackClient would not have gotten as far as it has without them.
Thank You.
dt
/me looking for one more post-Summit beer-debrief in the hotel lobby
next month...
--
Dean Troyer
dtro...@gmail.com
__
[followup...]
On Sat, Sep 9, 2017 at 4:51 PM, Dean Troyer wrote:
> [0] https://review.openstack.org/#/c/485232
I rebased this one to see where we stand with just removing the
'volume' service type.
dt
--
Dean Troyer
dtro
//review.openstack.org/#/c/485232
[1] https://review.openstack.org/#/c/453320 (abandoned)
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@list
we all stay on the same page better.
This is a great example of why attributes that are actually used
elsewhere should be defined in the API rather than just picked out of
a collection of metadata/properties.
dt
--
Dean Troyer
dtro.
ge has not been released yet, the current
plan is to make its first release when OSC 4 (next major release) is
released.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions
are (or
have now) fallen behind similarly to what we know to be the case with
deployments on releases, only maybe not quite as far?
dt
[0]
https://devops.com/automic-empowers-cloud-continuous-delivery-openstack-integration/
--
Dean
splitting out the low-level REST API layers
into a stand-alone piece that shade, SDK and OSC can all benefit from
would be our best course, but then I have been wrong about this
layering thing in the past, so I throw it out there to have something
that can be used to push against to get what everyone
up the migration.
If I find a doc that tells me how to set up a VM with a Neutron
network and ports and subnets and floating IPs that uses curl, I'm not
reading farther.
dt
--
Dean Troyer
dtro...@gmail.com
__
Will be there if possible.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstac
ed this long, but they have mostly because they were/are
just barely good enough that nobody wants to fund replacing them.
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsub
at
> route I'm happy to do so.
I would keep the output fields the same. If --minimal used to show
empty fields because the lookup was skipped, it would be OK to now
populate those, but I wouldn't add them just because you have the data
now without the looku
s about, and is the setting
for another example of where we should be careful with documentation
and 'officialness' around projects that disappear, lest we repeat the
experiences with PostgreSQL and have deployers make choices based on
our docs that do not reflect reality
never going to happen. We've seen how far
single-vendor projects have gone, and none of them reached that level.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsub
a common process model to follow, and any choice to
deviate from that is their own.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...
not sure that the actual repo is the issue, are we having problems
getting reviews to approve these? I don't see this but I'm also not
tracking the time to takes for them to get approved.
I believe it is just going to have to be a social thing that we need
to continue to push fo
ber of
different ones that are actually more efficient in the long run.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openst
image names when the non-unique names _do_ identify a single
result). Having that control lets me give the user more options in
handling edge cases.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing L
n of how to actually do this? If we had some
side-channel to return results metadata then this config change would
be discoverable after-the-fact, which in this case would be acceptable
as the condition checking happens after (at least some of) results are
returned anyway.
dt
--
Dean T
REST layer that they then compose and wish I had
been more persistent then.]
[0] https://github.com/jaypipes/enamel
[1] http://git.openstack.org/cgit/openstack/oaktree
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Develop
aving it approved.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cg
ature).
dt
P.S. I used 'tc-member' to catch both singular and plural forms.
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...
not add a new channel and do like the increased
traffic in -dev as of the last few months, but right now I think -tc
may be warranted.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage q
ext week is soon enough to extend Netwon's
EOL date, but starting in August most certainly is too late. (Newton
is our first realistic opportunity based on the LTS status of the
current testing configurations.)
Oh, and the number zero task is to make sure our stable team PTL ca
for these things too, and not just "enterprise
ready" or "telco ready" or "GPU ready" or whatever their particular
shiny thing is this year.
Make long term releases important on corporate bottom lines and it
WILL become a thing.
dt
--
Dean Troyer
dtr
ets help them help themselves.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.
issues regarding _when_ auth plugins get loaded that
differ between Shade and OSC's usage. once we complete resolving that
the level of reuse should be able to go up substantially.
dt
--
Dean Troyer
dtro...@gmail.com
_
the global
options, maintaining multiple client contexts, etc.
Thanks for sharing!
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ
//eavesdrop.openstack.org/#OpenStackClient_Team_Meeting
[1]
https://docs.openstack.org/developer/python-openstackclient/backwards-incompatible.html#release-3-10
[2]
https://docs.openstack.org/releasenotes/python-openstackclient/unreleased.html#id1
--
Dean
ver, and I do
believe you are right Rocky that is something we should get more
proactive with regards to our neighboring communities.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (n
On Fri, Apr 14, 2017 at 9:50 AM, Dean Troyer wrote:
> [0] https://www.openstack.org/legal/bylaws-of-the-openstack-foundation/
> [1]
> https://governance.openstack.org/tc/reference/principles.html#one-openstack
Rats, I missed the UC charter:
[2] https://governance.openstack.org/uc/
ndation, and if we sell a few boxes or service
contracts or chips along the way, our sponsors are happy too.
dt
[0] https://www.openstack.org/legal/bylaws-of-the-openstack-foundation/
[1] https://governance.openstack.org/tc/reference/principles.html#one-openstack
--
Dean Troyer
dtro...@gmail.com
) to ensure some
planning is possible.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://li
known only by their abbreviation, and this usage
is in fact expected by users. In the end, picking commands that are what
users would expect to search for is what they appreciate the most.
dt
--
Dean Troyer
dtro...@gmail.com
_
world-wide participation
(I read ahead) Dims mentions personal conversations with some backing
away from running for the TC due to the meeting time, I wonder how
much language has been a factor for others?
dt
--
But you might be unhappy about the removal of py27
from distros just yet, as not all of OpenStack is py3 ready. We
should just upgrade all that code...
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development M
o our current realities.
I was excited to see the TC vision proposal released for general
comment and think this is a great opportunity to come together on
goals and ideals for our future. Please read it if you have not
already! https://review.openstack.org/#/c/453262
dt
--
. There are other similar uses.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.o
I am Dean Troyer and would like to nominate myself as a candidate for
re-election to the Technical Committee.
I have been around OpenStack for a long time, primarily working on
DevStack, Grenade and OpenStackClient.
OpenStack has been going through the maturation process in the last
year or two
stent, but the current names will probably never
change, we'll just have the qualified names for those who prefer to
use them.
Flavor is my favorite example of this as we add network flavor, and
others. It also illustrates the 'it isn't a namespace' as it will
become 'serv
On Mon, Mar 20, 2017 at 4:36 PM, Adrian Otto wrote:
> So, to be clear, this would result in the following command for what we
> currently use “magnum cluster create” for:
>
> openstack coe cluster create …
>
> Is this right?
Yes.
dt
--
Dean Troyer
r?' question. No underscores
please, and in fact no dash here, resource names have spaces in them.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstac
On Fri, Mar 17, 2017 at 8:20 AM, Saverio Proto wrote:
> Is LBaaS even going to be implemented in the unified openstack client ?
No, it will be implemented as a separate OSC plugin. This is true for
all of Neutron's "advanced services" projects.
dt
--
Dean Troyer
eployment projects that are also designed
specifically to run services with minimal base requirements.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack
thers have
also shared a similar sentiment, including the tools they use to
achieve that result. I fully expect that there is a significant
number of people for whom the current situation is not working well
_for them_, and some of those folk were
riptions of who this proposal is not
intended to address, who exactly is expected to benefit from more
mailing lists?
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe
Unfortunately this is (was??) required for
libvirt live migration to work so is likely to not be an edge case in
deployments.
The safest read-back approach would be to generate both ISO9660 and
VFAT (if configured) and only read back from the ISO version. But
yuck, two config drive images...sti
reason for us to enable that sort of workflow to get worse by
extending the availability of that initial password.
We do not break existing users by ignoring the admin password on
subsequent config drive images. Of course I can always be
misunderestimating the "innovation" of users makin
cision are made for us by those member companies promoting
their own priorities (your example of Ansible contributions is one).
But as a community we have an opportunity to express our desires and
potentially influence those decisions.
dt
--
Dean Troyer
dtro...@gmail.com
__
ut the name like the browser User-Agent header nonsense.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subj
guration, which is by no
means authoritative.
There was a beginning of a service catalog type registry [3] that has
not gone beyond an initial proposal. Sean Dague recently revived this
and I believe it will be discussed next week at the PTG.
dt
[3] https://git.openstack.org/cgit/openstack/ser
ll sizes and types of deployments. I'll leave that for
$SUMMIT_COLD_BEVERAGE conversations for now.]]
dt
[0] Am I the only one who simply can not read 'LCOO' as anything other
than 'loco'? :)
--
Dean Troyer
dtro...@gmail.com
___
set of notes by walking the stable release pages
now.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsub
or notes that many projects have...
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.op
On Fri, Jan 20, 2017 at 10:46 AM, Dean Troyer wrote:
> I've proposed a couple of unit tests that appear to me to illustrate
> what OSC's functional test found. [0] runs on top of the revert, so
> this is the 'before' check, and [1] runs with the community image
&g
est found. [0] runs on top of the revert, so
this is the 'before' check, and [1] runs with the community image
change and should show the v1 breakage. As is often heard, "it's
working for me that way in DevStack" :)
dt
[0] https://review.openstack.org/
lance/commit/265659e8c34865331568b069fdb27ea272df4eaa
I've posted a revert of 265659e8c34865331568b069fdb27ea272df4eaa due
to the breakage of API v1 this late in the cycle.
A couple of attempts on my part to see why the Glance unit tests did
not catch this have fallen short due to ENO_CAFFIENE.
dt
--
Dean Troyer
nterested,
> and/or make your interest known to scottda, mordred, or edleafe.
IIRC there may be some cross-project rooms available, but I can also
offer time/space in the OpenStackClient room for this discussion if
needed.
dt
--
the 'backup' resource has
been deprecated and renamed as 'volume backup'. We could possibly
also do this with 'object' and 'container' from Swift, we will be
doing this with other resource
at least two specific and distinct meanings in OpenStack to only add
confusion for yet another use at all.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsub
in particular, files like AUTHORS and sample config files, which
IIRC are generated and included in tarballs.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage ques
That CLI doesn't exist yet,
and I do not see another reason (yet?) to include this in the initial
task list.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Uns
however, help ease the concerns many have around static linking of
libs.
dt
[0] https://blog.gopheracademy.com/advent-2016/saga-go-dependency-management/
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing L
2] https://etherpad.openstack.org/p/golang-infra-work-plan
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubsc
The odd week OpenStackClient meeting at 19:00 on Nov 24 is cancelled
due to the US holiday. We will see you all again on Dec 1 at 13:00
UTC in #openstack-meeting-3
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack
On Mon, Nov 21, 2016 at 9:05 AM, Csatari, Gergely (Nokia -
HU/Budapest) wrote:
> Is there any way to configure allowed-address-pairs in osc?
These options are under review in
https://review.openstack.org/#/c/356219/ and should be merged soon.
dt
--
Dean Troyer
dtro...@gmail.
d, this will not be easy for Swift or Glance (others?), but
if the impact to deployers can be quantified it makes it easier to
spend energy here.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mail
nStackClient and Shade,
not neutronclent. That bug is up to the Neutron team to decide.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-
cloud
consumers to operators to OpenStack developers) has been regarding how
much they appreciate the command consistency. This is our biggest
feature.
dt
--
Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing
1 - 100 of 396 matches
Mail list logo
