ll need the attribute on the network object
specifying whether this is permitted or not: we can then create
dedicated networks per test run with that set, so even if v1 of the
patches just turn it on for every port on such a network, we'd be set.
Overall though, its fantatic you have somethin
od start, jml or thomi or jelmer (amongst
others) can review and land and do a release - I'm not critical path.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.o
the chown migration should activate if either a) the image
doesn't have fully fixed uuids, or b) the marker file is missing, or
c) the marker file has a different uuid and indicates the prior image
didn't have fixed ids.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cl
world contact details should something urgent which
only I can do [there should be no such things] turn up.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
On 30 September 2014 14:05, Robert Collins wrote:
> I'm poking around now. It looks like pip install -e outside a venv
> writes to /usr/local/lib/python2.7/dist-packages, which is pure crack
> - dist-packages is for the distro, site-packages for pip. Sigh. Also
> writing to /u
r the distro, site-packages for pip. Sigh. Also
writing to /usr/local/lib when the python prefix is /usr. More
weirdness.
Will be back with more soon :)
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 30 September 2014 03:10, Doug Hellmann wrote:
>
> On Sep 28, 2014, at 5:00 PM, Robert Collins wrote:
> As far as I know, the client libraries aren’t being released as alphas. The
> Oslo libraries are, but they aren’t “public” in the same sense — they’re an
> internal part of
On 27 September 2014 10:07, Robert Collins wrote:
> TripleO has been running pip releases of clients in servers from the
> get go, and I've lost track of the number of bad dependency bugs we've
> encounted. We've hit many more of those than bad releases that crater
> t
he same way that distributions offer production stamps
about Nova, distributions that use TripleO offer production stamps
about Nova :).
And I think this is James's point. Your category 2 above saying that
TripleO is different is just confused: TripleO is a deployment
architecture [evolving into
e've hit many more of those than bad releases that crater
the world [though those have happened].
And yes, alpha dependencies are a mistake - if we depend on it, its a
release. Quod erat demonstratum.
-Rob
--
Robert Collins
Distinguished Technolo
That is, we don't follow that workflow for service
users today.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
to see shrinking of the integrated release
process - we've a lot of overheads there, and testing more directly
can get better and faster results.
So I guess I'm saying:
Lets decouple 'what is openstack' from 'what we test together on
every commit'.
We can debate Ri
On 24 September 2014 11:03, Robert Collins wrote:
> So... FWIW I think I've got a cleaner implementation of namespaces
> *for our context* - it takes inspiration from the PEP-420 discussion
> and final design. It all started when Mike reported issues with testr
>
not ever specify destination host, because Nova does not
> allow that, nor should it. It does want to isolate failure domains so
> that all three Galera nodes aren't on the same PDU, but we've not really
> gotten to the point where we can do that yet.
Nit: Nova allows it, and
he OpenStack Deployment
*program*, aka TripleO. The TC blesses social structure and code
separately: no part of TripleO has had its code blessed by the TC yet
(incubation/graduation), but the team was blessed.
I've no opinion on the Murano bits you raise.
@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Nuts, thank you.
On 24 September 2014 14:28, Mike Bayer wrote:
>
> On Sep 23, 2014, at 7:03 PM, Robert Collins wrote:
>
>> On 29 August 2014 04:42, Sean Dague wrote:
>>> On 08/28/2014 12:22 PM, Doug Hellmann wrote:
>> ...
>>>> The problem is that
; its install script tries to launch the daemon, and that fails.
>
> Regards,
> Mike
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
Robert Collins
Distinguished Technologist
old a separate weekly
> one hour IRC meeting on Mondays at 2000 UTC in #openstack-meeting [3].
>
>
> This project has been discussed with the current TripleO PTL (Robert
> Collins) and he seemed very supportive and agreed with the organization of
> the project outlined above.
he pre-PEP420 world)
- a tiny pbr bugfix: https://review.openstack.org/123597
- and a patch like so to each project: https://review.openstack.org/123604
I have such an olso package https://github.com/rbtcollins/oslo, if
this sounds reasonable I will push up an infra patch to create it.
ate with the tz's we cover ;)).
http://eavesdrop.openstack.org/meetings/tripleo/2014/tripleo.2014-09-23-19.03.log.html#l-239
-Rob
Cheers,
Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
excellent intra-layer features/quality
etc, but perhaps cross-layer would become the poor stepchild. And - I
think thats ok. I think it would help overall.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
p kidding ourselves - OpenStack is not a lean little
beastie anymore: its a large scale distributed system. Swift is doing
exactly the right thing today - I'd like to see more of that.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
On 23 September 2014 08:09, Jay Pipes wrote:
> On 09/22/2014 03:36 PM, Robert Collins wrote:
>> I'm going to push on this a bit further. Mocking is fine in many
>> cases, but it encodes dependencies from within your objects into the
>> test suite: e.g. that X will
d-hoc fakes are no better than mocks in this regard, but verified
fakes are substantially better and give nearly the same performance as
mocks, with (generally) better diagnostics, fidelity and low
fragility. Where we don't have verified fakes, making a single robust
fake for the interface is a good alternative - and I'd like to see
OpenStack do more of this, not less.
https://thoughtstreams.io/glyph/test-patterns/5952/ is a good post
from Glyph describing them.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
myopia, solving things just in the deployment context, and
I need to do better than that :).
I look forward to other TripleO folk putting their hat into the ring -
I'll support whoever wins in anyway I can, and I'm still going to be
here hacking on TripleO and reviewing what folk ar
ing heat in standalone mode
> who may not have (or want) an additional event stream service thing.
They can install Zaqar in standalone mode too, if they need the
functionality. I don't see that as a good reason to keep two
implementations of basically the same thing.
-Rob
--
Rob
://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
t; largely untouched.
Thats more complicated than is needed. We've already consolidated all
the post and pre-release stuff into one codepath; right now it errors
on an illegal operation, which is also fine for the purpose of this
discussion.
All we need is in the logic is to replace 'd
my box but a cloud user that just want to get his VMs running isn't
> going to be happy, especially on Windows.
>
> dt
OOI were thouse changes API breaks or were we depending on nonpublic aspects?
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
idea be
> put aside as unworkable.
>
> I intend to pursue the single-point API service that I have described as a
> way of moving forward in prototyping a pure-Javascript OpenStack Dashboard.
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
27;replicas' in
> Ceilometer code, but I suggested 'distribution_quality' or something
> similarly descriptive in an earlier e-mail.
I think you misunderstand the code. We do assign the number of
partitions beforehand - its approximately fixed and indepe
nce to
the quality of the code that lands via the second +2 review. I observe
that our big themes on quality are around systematic changes in design
and architecture, not so much the detail of each change being made.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
th by sending them traffic.
Because a) the post is whats disagreed with not the person; b) without
the post to read we'd have no context here.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
Op
is that a deployer would do before pushing
> this out to their users.
Add into that their deployment support - e.g. do they have TripleO
support // Chef // Fuel // Puppet etc etc etc.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
__
the plumbing use case, we might be able to simplify our stack
substantially - and that would pay off vs the new deployment overhead
of a new component.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
Ope
On 4 September 2014 23:42, Nejc Saje wrote:
>
>
> On 09/04/2014 11:51 AM, Robert Collins wrote:
> It doesn't contain that term precisely, but it does talk about replicating
> the buckets. What about using a descriptive name for this parameter, like
> 'distribution_qu
mapped to it
- replicas - number of buckets a single key wants to be mapped to
- partitions - number of total divisions of the hash space (power of
2 required)
> I've opened a bug[3], so you can add a Closes-Bug to your patch.
Thanks!
-Rob
--
Robert Collins
Distinguished Technologist
HP Conv
On 4 September 2014 08:13, Robert Collins wrote:
> On 3 September 2014 23:50, Nejc Saje wrote:
>
> Forgive my slowness :).
>
>> Disclaimer: in Ironic terms, node = conductor, key = host
>
> Sadly not inside the hash_ring code :/. host == conductor, key == data.
>
>
On 4 September 2014 00:13, Eoghan Glynn wrote:
>
>
>> On 09/02/2014 11:33 PM, Robert Collins wrote:
>> > The implementation in ceilometer is very different to the Ironic one -
>> > are you saying the test you linked fails with Ironic, or that it fails
>&
oslo for use in both projects
>>> or
>>> we can both use an external library[3].
>>>
>>> Cheers,
>>> Nejc
>>>
>>> [1] https://review.openstack.org/#/c/113549/
>>> [2]
>>> https://review.openstack.org/#/c/113549/21/ceilomet
We would benefit a great deal from having this sooner.
On 3 September 2014 20:11, Joshua Hesketh wrote:
> On 9/3/14 10:43 AM, Jeremy Stanley wrote:
>>
>> On 2014-09-03 11:51:13 +1200 (+1200), Robert Collins wrote:
>>>
>>> I thought there was now a thung where
ndled together into the third component.
The reason I prefer the last option over the second last, is that we
don't have any mechanism to skip versions other than tagging today -
and doing an alpha-0 tag at the opening of a new cycle just feels a
little odd to m
t; only work on a list of files. We can then discuss how best to match
> things in devstack so we don't add files but miss checking them.
>
> -i
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> htt
106167
(Keystone/LDAP integration)
That patch had a -1 on Aug 16 1:23 AM: but was quickyl turned to +2.
So this patch had a -1 then after discussion it became a +2. And its
evolved multiple times.
What should we be saying here? Clearly its had little review input
over its life, so I think its
e zuul can use a different account
per pipeline?
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ypi.python.org/pypi/hash_ring
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
__
Fwiw I would like to see such dependencies listed so that we can properly
install trunk via automation.
On 24 Aug 2014 10:43, "Maru Newby" wrote:
>
> On Aug 14, 2014, at 1:55 PM, Ihar Hrachyshka wrote:
>
> > Signed PGP part
> > FYI: I've uploaded a review for openstack/requirements to add the
>
journaled filesystem will take quite a bit to do a full fsck.
>
> The inability to gracefully shutdown in a reasonable amount of time
> is an error state really, and I need to go to the box and inspect it,
> which is precisely the reason we have ERROR states.
>
> Thanks fo
tests not to call
> setUp() and tearDown() twice. This will be the requirement to unpin
> the version of the library.
>
> So, please review, backport, and make sure it lands in project
> requirements files.
In hindsight I should have introduced a warning for a period of time
t
On 20 August 2014 15:28, Robert Collins wrote:
> I think you mean it 'can be argued'... ;). And I'd be happy if folk in
> those communities want to join in the deployment program and have code
> repositories in openstack/. To date, none have asked.
Sorry, that was incom
kbooks for inclusion in the Deployment program, to live under
> the openstack/ code namespace. Same for the Puppet modules.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 20 August 2014 13:26, Robert Collins wrote:
> Don't you hate it when just after you hit send...
> This one is actually fine, as is all the ones where the tag is a beta
> of the same version. I'm fixing this and another bug and will follow
> up shortly with a correct l
Don't you hate it when just after you hit send...
On 20 August 2014 13:12, Robert Collins wrote:
> Hi, in working on pbr I have run into some bad data in our
> setup.cfg's. Details are here:
> https://etherpad.openstack.org/p/bad-setup-cfg-versions
>
> Short version: we
e/ospurge/origin/master
2014.1.0 too low vs tag 2014.2.0 in stackforge/solum/origin/cookiecutter
2014.1.0 too low vs tag 2014.2.0 in stackforge/solum/origin/master
2014.1.0 too low vs tag 2014.2.0 in stackforge/solum/origin/readme-start
--
Robert Collins
Disti
tion
is about opening up +A to the whole Tripleo core team on specs.
Reviewers, and other interested kibbitzers, please +1 / -1 as you feel fit :)
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing lis
#x27;d like to see more unification of implementations in TripleO - but I
still believe our basic principle of using OpenStack technologies that
already exist in preference to third party ones is still sound, and
offers substantial dogfood and virtuous circle benefits.
-Rob
--
Robert Collins
D
you have suggestions as to how to improve this
> mechanism cleanly without sacrificing backwards compatibility?
We could make a heuristic (there is a patch up already to do that for
dib) that looks at the unpacked content to decide what to do.
-Rob
--
Robert Collins
Distinguished Technolo
sight in coverage).
Cheers,
Rob
1: https://review.openstack.org/114093
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
er discussion, once we had rough consensus at the
f2f.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
n it off and try something else.
>
> I'm confused by the hostility about this gate job - it is costing us
> nothing, if it turns out to be a pain we'll turn it off.
>
> Rally as a general tool has enabled me do do things that I wouldn't
> even consider
On 13 August 2014 11:05, Robert Collins wrote:
> I've reproduced the problem with zane's fix for the validation error -
> and it does indeed still break:
> "| stack_status_reason | StackValidationFailed: Property error :
> NovaCompute6:
> | | k
On 12 August 2014 10:46, Robert Collins wrote:
> On 12 August 2014 07:24, Dan Prince wrote:
>> On Tue, 2014-08-12 at 06:58 +1200, Robert Collins wrote:
>>> Hi, so shortly after the HOT migration landed, we hit
>>> https://bugs.launchpad.net/tripleo/+bug/1354305 whic
it a standard - possibly lint on it,
certainly fixup things when we see its wrong - to alpha-sort such
structures: that avoids the textual-merge failure mode of 'append to
the end'.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
hanks for being clear about this (is it in the deployer docs for heat?).
That said, nova, neutron and other projects are defaulting to
one-worker-per-core, so I'm surprised that heat considers this
inappropriate, but our other APIs consider it appropriate :) Whats
different about heat that make
org/#/c/112936/
>
> (BTW it would be great if threads about critical bugs in Heat had [Heat] in
> the subject - I almost missed this one.)
Sorry, was thinking this was more a TripleO issue - but I'm glad its a
shallow heat issue instead :)
On 12 August 2014 07:24, Dan Prince wrote:
> On Tue, 2014-08-12 at 06:58 +1200, Robert Collins wrote:
>> Hi, so shortly after the HOT migration landed, we hit
>> https://bugs.launchpad.net/tripleo/+bug/1354305 which is that on even
>> quite recently deployed clouds, the mi
so need to be able to recognise them in
review / design, and call them out so we can fix them early rather
than deep down the pike.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
Ope
it reflog - you can recover all of your history in high fidelity
(and there are options to let you control just how deep the rabbit
hole goes).
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing
On 7 August 2014 15:31, Christopher Yeoh wrote:
> On Thu, 7 Aug 2014 11:58:43 +1200
> Robert Collins wrote:
...
> At the moment when cleaning up we don't know if a port was autocreated
> by Nova or was passed to us initially through the API.
That seems like a very small patc
m (when we can do an API rev) we should just be
> getting rid of the automatic port creation completely with the updated Nova
> API. I don't see why the Nova API needs to do proxying work to neutron to
> create the port when the client can do it directly with neutron (p
On 6 August 2014 17:27, Tom Fifield wrote:
> On 06/08/14 13:24, Robert Collins wrote:
>> What happened to your DB migrations then? :)
>
>
> Sorry if I misunderstood, I thought we were talking about running VM
> downtime here?
While DB migrations are running things like the
On 6 August 2014 17:22, Tom Fifield wrote:
> On 06/08/14 13:18, Robert Collins wrote:
>>
>> On 6 August 2014 16:57, Tom Fifield wrote:
>>
>>>> Note, however, that nobody is suggesting not having a migration path.
>>>> I'm just suggesting relaxing
we should stop
releasing OpenStack at all for an extended period while we redo a
tonne of stuff.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
27;d encounter
unexpected cross-chatter between them on things like external bridge
flows.
Thoughts?
For now, we're going to have to run with a limitation of only one
vif-plugging hypervisor type per machine - we'll make the agent
hostname match that of the nova compute that needs VIFs p
Thanks!
On 5 August 2014 06:40, Dan Prince wrote:
> On Sun, 2014-08-03 at 07:59 +1200, Robert Collins wrote:
>> We had a few whiteboard photos taken during the sprint, but I can't
>> find where they were posted :/
>>
>> Right now I'm looking for the one wit
We had a few whiteboard photos taken during the sprint, but I can't
find where they were posted :/
Right now I'm looking for the one with the list of priority CI jobs,
-Rob
--
Robert Collins
Distinguished Technologist
HP Conve
On 16 July 2014 03:45, Debojyoti Dutta wrote:
> https://etherpad.openstack.org/p/SchedulerUseCases
>
> [08:43:35] #action all update the use case etherpad
> athttps://etherpad.openstack.org/p/SchedulerUseCases
>
> Please update your use cases here ..
Added.
-Rob
folk who are running boxed
products (e.g. RackSpace private cloud) + any other deployment
segments you might be aware of.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
either its not an issue (in
which case why are we putting all this overhaul effort in), or else
deployers have already tackled it in general and its not felt as a
current pain point (or perhaps we didn't get enough folk in the
room...)
-Rob
--
Robert Collins
Distinguished
; But I could not find any coding practices guide for PowerShell on
> https://wiki.openstack.org/wiki/CodingStandards. Is there a separate link
> that I should look at..?
You may need to make some up.
-Rob
--
Robert Collins
Distinguished Tec
but its going to
take time to align them with what deployers are actually running - and
we may have it wrong. I want to *add into the mix* a committment to
run what our users are running, so that we can:
- tell if we got it wrong
- get developers seeing what deployers see
-Rob
ps://review.openstack.org/#/c/91446/
Sorry no- you've missed my point: that review is the *new standards
for logging*, I'm talking about capturing what is *in production now*,
and changing the *defaults* - a one-line patch to each project, and
removing the overrides from devstack.
--
Robert
ady) We can revisit the discussion of decreasing Tempest's size once
> everyone's figured out the per project functional testing. This will also give
> us time to collect longer term data about test stability in the gate so we can
> figure out which things are actually valu
gents (one in dvr-snat mode, one in dvr mode) on each
node?
Isn't it possible to avoid this and have just one l3 dvr mode ?
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
Ope
short term,
making the default meet our deployments seems realtively easy and
immensely sane.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Sure. Put it in the agenda perhaps Tuesday morning
On 20 Jul 2014 12:11, "Chris Jones" wrote:
> Hi
>
> I also have some strong concerns about this. Can we get round a table this
> week and hash it out?
>
> Cheers,
> Chris
>
>
> >> On 20 Jul 2014, at 14:51, Dan Prince wrote:
> >>
> >>> On Thu, 20
<3
-Rob
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
every
host in the entire cloud into ram on every scheduling request),
scalability (e.g. elegantly solving the current racy behaviour between
different scheduler instances) and begin the work to expose the
scheduler to neutron and cinder.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
n't need two bridges for CI overclouds - the rearranging of things
I've done over the last couple of weeks means we no longer *break* the
build in bridge, and so we can use br-ex for everything.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
_
re
> reviewer team.
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
_
y thoughts?
> Thanks.
>
> https://dracut.wiki.kernel.org/index.php/Main_Page
>
> -Ben
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.opens
trike again and require it for their employees?
>
> Thanks,
> John
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/
gt;
>
>
> Please let me know your thoughts/suggestions on the same. Also if there is
> anything that needs to be addressed before adoption under TripleO.
>
>
>
> Regards,
>
> Om
>
>
> ___
> OpenStack-dev mailing list
as I would
> like to finish up this road to mod_wsgi based Keystone as early in the Juno
> cycle as possible.
>
> Cheers,
> Morgan Fainberg
>
>
> —
> Morgan Fainberg
>
>
>
> ___
>
up.
> Just using different extra_spec in nova flavor to specifiy hw_model. Is it a
> good idea?
>
>
>
> Regards,
>
> Taurus
>
>
> _______
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi
ted to you be bitten by the
first-line rule, which exists for API extractors (such as
help(module)) so that they have a useful, meaningful summary they can
pull out. I think it aids immensely in docstring readability - and its
certainly convention throughout the rest of the Python universe, so
IMO
Well we probably need some backwards compat glue to keep deploying
supported versions. More on that in the spec I'm drafting.
On 21 Jun 2014 12:26, "Dan Prince" wrote:
> On Fri, 2014-06-20 at 16:51 -0400, Charles Crouch wrote:
> >
> > - Original Message -
> > > Not a great week for Triple
l use of the individual or entity
>> to which this message is addressed, and unless otherwise expressly
>> indicated, is confidential and privileged information of Rackspace. Any
>> dissemination, distribution or copying of the enclosed material is
>> prohibited. If you receive this transmission in error, please notify us
>
Performance hint... Each API call should be fast but the orm wrapper is
very aggressive about asking the server for objects. So build local lookup
tables and use those via the id ... This generally solves lp API
performance issues :)
On 19 Jun 2014 12:25, "Joe Gordon" wrote:
>
>
>
> On Sat, Jun 7
501 - 600 of 1124 matches
Mail list logo
