review, and see *all* the wholes that we'll have, rather than
cherrypicking issues: what passes such a policy for nova-KVM is likely
not sufficient for ironic.
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
On 25 Jan 2014 15:11, Clint Byrum cl...@fewbar.com wrote:
Excerpts from Devananda van der Veen's message of 2014-01-22 16:44:01
-0800:
What Tuskar wants to do is layer workloads on top of logical and physical
groupings. So it would pass to Nova Boot 4 machines with (flavor)
and
On 23 Jan 2014 13:45, Devananda van der Veen devananda@gmail.com
wrote:
So, a conversation came again up today around whether or not Ironic will,
in the future, support operations on groups of nodes. Some folks have
expressed a desire for Ironic to expose operations on groups of nodes;
+1
On 25 Jan 2014 14:33, Adrian Otto adrian.o...@rackspace.com wrote:
Solum Core Reviewers,
I propose the following changes to solum-core:
+asalkeld
+noorul
-mordred
Thanks very much to mordred for helping me to bootstrap the reviewer team.
Please reply with your votes.
Thanks,
.
Instance Type would be horribly confusing IMNSHO - too close to
http://aws.amazon.com/ec2/instance-types/ - which it is not at all
like.
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing
go :)
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
tests (like triggering on nova changes).
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
on.
In order to understand the relationship with GRO, what are the CPU usage
levels on the receiving node with and without GRO enabled?
Salvatore
On 22 January 2014 17:26, Rick Jones rick.jon...@hp.com wrote:
On 01/22/2014 03:01 AM, Robert Collins wrote:
I certainly think having the MTU set
. The optimised case merely deploys faster.
Finally, remember that the undercloud machines have small (~170K)
numbers of files - which takes 28 seconds to stat cold - so rsyncing a
single changed file should be ~30seconds. Thats comparable (if not
better :)) than the time to run yum or apt.
-Rob
--
Robert
On 22 January 2014 21:28, Ian Wells ijw.ubu...@cack.org.uk wrote:
On 22 January 2014 00:00, Robert Collins robe...@robertcollins.net wrote:
I think dropping frames that can't be forwarded is entirely sane - at
a guess it's what a physical ethernet switch would do if you try to
send a 1600
with
this, in things like unittests and functional tests, even while
tempest scenarios are kept running.
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev
on instances and prevent packet
fragmentation over the GRE tunnel:
1
dhcp-option-force=26,1400
Note that multiple people have been reporting this basic issue since
approximately H, so it should be easy to reproduce.
Cheers,
Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP
On 22 January 2014 10:50, Kashyap Chamarthy kcham...@redhat.com wrote:
[CC'ed libguestfs author, Rich Jones]
Heya,
On 01/21/2014 07:59 AM, Robert Collins wrote:
I was reminded of this while I cleaned up failed file injection nbd
devices on ci-overcloud.tripleo.org :/ - what needs to happen
On 22 January 2014 03:03, Russell Bryant rbry...@redhat.com wrote:
On 01/20/2014 09:29 PM, Robert Collins wrote:
I was reminded of this while I cleaned up failed file injection nbd
devices on ci-overcloud.tripleo.org :/ - what needs to happen for us
to change the defaults around file injection
On 22 January 2014 10:01, Ian Wells ijw.ubu...@cack.org.uk wrote:
On 21 January 2014 21:23, Robert Collins robe...@robertcollins.net wrote:
In OpenStack we've got documentation[1] that advises setting a low MTU
for tenants to workaround this issue (but the issue itself is
unsolved
failing.
The goal though is to have an independent system; perhaps marking all
the tests that still depend on tendrils of nova 'skipped' and then
work on burning down the skips to 0 is a better approach than making
it easy to have such dependencies?
-Rob
--
Robert Collins rbtcoll...@hp.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
:). I'm presuming the steps needed to change the
default are:
- a blueprint, as it's changelog worthy for the release
- a DocImpact patch that changes the default for drivers that
currently default it on
Anything else?
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP
of the baremetal service
on the disk, loaders etc etc, otherwise its difficult to assure your customer.
I think LXC/openVZ/Docker make pretty good compromises in this space
BTW - low overhead, bare metal performance, no root access to the
hardware.
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished
On 19 January 2014 04:48, Sean Dague s...@dague.net wrote:
On 01/18/2014 01:06 AM, Robert Collins wrote:
Launchpadlib which builds on wadllib did *exactly* that. It worked
fairly well with the one caveat that it fell into the ORM trap - just
in time lookups for everything with crippling
a whitelist of audited message handlers, thats fine. Of
course, if the message handlers haven't been audited, who knows whats
lurking in there.
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing
that don't have
comprehensive mutual trust, that it's really not viable today (even on
relatively recent platforms IMNSHO).
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev
to see every vendor publish a
passing run against each milestone cut. That in and of itself would
be a huge step in the right direction in my opinion.
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
OpenStack
/listinfo/openstack-dev
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
tooling is an odd concept
in itself, but thats a different discussion.
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org
On 18 January 2014 06:42, John Griffith john.griff...@solidfire.com wrote:
On Fri, Jan 17, 2014 at 1:15 AM, Robert Collins
robe...@robertcollins.net wrote:
Maybe this is going a bit sideways, but my point was that making a
first step of getting periodic runs on vendor gear and publicly
firmware update capabilities it's not clear to me how this
could be reliably solved.
Slowly and carefully :)
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev
compressed data? Is it really noticable?
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo
upgrades are possible (or downgrades are required).
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman
:)
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
be at least thought of.
Sounds a little bit crazy though, I recognize it :).
Launchpadlib which builds on wadllib did *exactly* that. It worked
fairly well with the one caveat that it fell into the ORM trap - just
in time lookups for everything with crippling roundtrips.
-Rob
--
Robert Collins
On 18 January 2014 16:31, John Griffith john.griff...@solidfire.com wrote:
On Fri, Jan 17, 2014 at 6:24 PM, Robert Collins
robe...@robertcollins.net wrote:
Certainly - I totally agree that anything nothing. I was asking
about your statement of not having enough infra to get a handle on
what
4. Send a few packets with a nonce in them to any of the
already meshed nodes, and those nodes can report what ip they
originated from.
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing
On 16 January 2014 22:51, Robert Collins robe...@robertcollins.net wrote:
I don't think 1 is a special case of 3 - interface based connections
are dependent on physical wiring,
How about 4. Send a few packets with a nonce in them to any of the
already meshed nodes, and those nodes can report
On 13 Jan 2014 12:15, Bhuvan Arumugam bhu...@apache.org wrote:
It behave differently when I list tempest tests. All tests are listed in
single line with unicode characters. The command exit with non-zero exit
code, with import errors. Any idea on whats going on?
The import errors are due to
?
Because (like for cinder) during the migration period we're
maintaining two copies one in Nova and one in Gantt. If we're
successful then once I is out we can delete the Nova copy.
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
of their project to do the same.
Am in.
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
and test it etc).
I think we should set some confidence interval - e.g. 95% - and then
from that we can calculate how many runs we need to be confident it
won't occur more than that often. The number of runs will be more than
3 though :).
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished
will have deprecated the nova scheduler code and have moved to
gantt.
We need to do the gantt client tree too, it's up but not sorted like
the server is. This tree is what nova should import to get the RPC
definitions to talk to gantt.
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished
for this.
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
is toxic about the few rules needed to handle common editors?
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin
are not especially
careful to confirm those patterns match *only* what's intended
(which also means gaining confidence in the nuances of git's pattern
matcher).
I read that as 'we don't test that our tarballs work'. No?
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP
to be incompatible without warning about that *until*
there is a [pre-]release of the new major version available
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev
On 11 January 2014 15:39, Jeremy Stanley fu...@yuggoth.org wrote:
On 2014-01-10 22:00:40 +1300 (+1300), Robert Collins wrote:
[...synchronized .gitignore across all projects...]
Out of curiousity, why wouldn't it work?
The example I gave earlier in the thread... one project wants
the whole
production-ready concept. So +1 on the other bits, but -2 on using
git.
We should use the git version when landing a change to the package,
the released version otherwise.
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
.
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
in packages to share effort between
teams installing OpenStack in more traditional ways and those getting
on the TripleO pipeline.
I'm not disputing the possible downsides intrinsic to packages,
particularly the not-at-scale temptation to create non automated
snowflakes :)
-Rob
--
Robert Collins
building on a packaging toolchain are going to
often be in catchup mode - I think we need to anticipate package based
environments running against releases rather than CD.
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev
On 7 January 2014 07:41, David Kranz dkr...@redhat.com wrote:
Thanks to all who looked at https://review.openstack.org/#/c/64733/. There
were a few minor issues I will address but the biggest one was the
suggestion to run each variation as a separate test case using
testscenarios. After
guarantees, so
the point when we will hit an incompatible change to a stable API is
the 2 transition.
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http
A bunch of the TripleO folk are going to be at LCA. I'd like to cancel
the meeting rather than get them all up at (IIRC) 3am.
If folk who aren't going want to hold the meeting, thats fine - but I
won't be around to chair :)
Cheers,
Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack
already.
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
machines and for some of them we choose to
subdivide', or should it be an undercloud service - 'you can ask for
machines or containers'.
To my mind there are too many unknowns to meaningfully design at this
point. We'll need to do a bunch of experiments to learn the
constraints
-Rob
--
Robert
match names we'd genuinely want to add.
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo
I'm going to skip this this month: with most folk having ~2 weeks of
leave there's only an effective 2 weeks of delta - both in practice
for new reviewers, and in changes to track for existing -core since
the last review - it seems a little pointless.
-Rob
--
Robert Collins rbtcoll...@hp.com
.
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
. But even if it didn't, the ephemeral volume is formatted by
the hypervisor, the one where resize is needed is the root device,
which is separate.
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev
for reviews that do need to move quickly,
then there is no need to solve the problem *differently* for reviews
that don't.
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev
into an arbitrary-time
warning period to users, if a cloud needs to.
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi
death. I suggest
not waiting for that and instead writing a new patch yourself.
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http
Thats certainly a logical extension to the system, but orthogonal to
fixing a bad default IMO.
Admins can already configure a filesystem per OS.
-Rob
On 20 December 2013 23:00, Daniel P. Berrange berra...@redhat.com wrote:
On Fri, Dec 20, 2013 at 09:21:54AM +1300, Robert Collins wrote
-bin/mailman/listinfo/openstack-dev
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Yuriy seems to have been doing reviews consistently over the last
three months, is catching plenty of issues.
He isn't catching everything, but I think he catches approximately as
much as other cores - none of us catch everything.
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished
*anyway* so I think
it's ok for the PTL (for instance) to not be at every meeting.
Thoughts?
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http
why baremetal deploys were slow :)).
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
On 16 December 2013 23:56, Thierry Carrez thie...@openstack.org wrote:
Robert Collins wrote:
https://wiki.openstack.org/wiki/BugTriage is a 10 step process: thats
not something we can sensible do over coffee in the morning.
Totally agree with that. The idea of those 10 steps was not meant
mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev
, linear IO for the target disk - much
better.
Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo
-gate or
devstack *other than* setting up the specific scenario, think thrice -
should it be a production default and set in the relevant projects
default config setting.
Cheers,
Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
We have official tags for most of the hypervisors, but not ironic as
yet - any objections to adding one?
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev
On 12 December 2013 21:59, Jaromir Coufal jcou...@redhat.com wrote:
On 2013/12/12 01:21, Robert Collins wrote:
On 12 December 2013 08:15, Tzu-Mainn Chen tzuma...@redhat.com
* MANAGEMENT NODE - a node that has been mapped with an
undercloud role
Pedantically, this is 'A node
the single
most important thing for TripleO right now, and with a need for
patches in four projects (Nova, python-novaclient, the API docs and
finally in heat to expose the use of it) there is still plenty of
room for folk to make sure they don't tread on each others toes.
-Rob
--
Robert Collins
is part of setting up the 'role configuration'.
Thanks for drafting this!
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org
something
([manual] allocation) that we don't offer.
We don't at the moment but we should :)
maybe :0
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
and third-party
testing? AIUI the criteria for acceptance is 'the thing is incubated
or integrated'.
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
to their metric, and proxy metrics will optimise to the
proxy, not to the primary goal - they can and usually will be
disasterous.
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
On 9 December 2013 23:56, Jaromir Coufal jcou...@redhat.com wrote:
On 2013/07/12 01:59, Robert Collins wrote:
* Creation
* Manual registration
* hardware specs from Ironic based on mac address (M)
Ironic today will want IPMI address + MAC for each NIC + disk/cpu/memory
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
, but not for anything that needs a full machine.
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
... I'm not debating that we
should have a list of free hardware - we totally should - I'm debating
how we frame it. 'Available Nodes' or 'Undeployed machines' or
whatever. I just want to get away from talking about something
([manual] allocation) that we don't offer.
-Rob
--
Robert Collins rbtcoll
from the bottom ('has GPU') and the constraints from the top ('needs
GPU') and letting Nova and Heat sort it out.
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev
to +2 land == more +2 bandwidth]
and helping the project as a whole.
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org
entirely possible to be good at one and
not the other, or just to do a lot of one and not the other. *And
thats OK*.
So all that said, I think the vote summary is:
- Ghe into core
- the proposed removals held for a month
And we'll re-evaluate in Jan.
-Rob
--
Robert Collins rbtcoll...@hp.com
to discard notifications during no subscriber.
Which is fine: the agent repulls the full set it's running on that
machine, and life goes on.
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing
On 7 December 2013 21:08, Clint Byrum cl...@fewbar.com wrote:
So what is needed is domain specific command execution and segregation
of capabilities.
Sounds rather like mcollective.
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
would say single node failure isn't catastrophic.
So we should have AMQP set to discard notifications if there is noone
listening: when an agent connects after an outage, it first starts
listening, then does a poll for updates it missed.
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Personas as a way to make
designs concrete and connected to user needs.
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi
On 7 December 2013 10:55, Matt Wagner matt.wag...@redhat.com wrote:
The 'management node' here is the undercloud node that Anna is
interacting with, as I understand it. (Someone correct me if I'm wrong.)
So it's not a bad idea to show its status, but I guess the mere fact
that she's using it
, for things that
currently have no topic.
- Why not filter for just topics locally, wouldn't that be equivalent?
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev
of the API's they are
presenting to users. I am totally confident that they are up to the
task, particularly if the folk that are working on Tuskar are there to
help Horizon folk understand better!
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
discuss it more real-time at the
coming TripleO meeting; and I suggest that the Horizon meeting should
also do that, and we can loop back to email with any new ideas or
concerns that that raised.
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
On 5 December 2013 06:55, James Slagle james.sla...@gmail.com wrote:
On Wed, Dec 4, 2013 at 2:12 AM, Robert Collins
Jan, Jordan, Martyn, Jiri and Jaromir are still actively contributing
to TripleO and OpenStack, but I don't think they are tracking /
engaging in the code review discussions
a file in the image with
that uuid, and outside the image we can write:
- all variables (no security ramifications now as this file can be
kept by whomever built the image)
- command line args
- version information for the toolchain etc.
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished
of discussions and
debugging plans and so forth.
Wiki pages are great for doing adhoc manuals and living
google-searchable reference material.
IMNSHO.
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev
/ we do that makes the bottleneck better makes everything
better. Anything else we do has pretty much no effect, other than
costing time and effort to do it, whatever it is.
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
into account that
setUpClass might do more than just fixtures, and certain guards are expected
to
be found in there.
So the point is to remove setUpClass use entirely. Please bear that in
mind in whatever you come up with.
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP
reviewers
(many hands, light work) - ideally with a distributed project like us,
most things would be looked at in 9-12 hours or less; however these
figures are much happier than nova, and nova still achieves pretty
good velocity!
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP
701 - 800 of 983 matches
Mail list logo
