to be no reason to do one release every 6 months of
olso.*, and doing so seems likely to only incur costs, since the
discipline needed to do regular semver with good backwards compat is a
discipline we're going to have to exercise anyway.
-Rob
--
Robert Collins
Distinguished Technologist
HP
Makes sense to me
On 18 Jun 2014 06:18, "Tim Bell" wrote:
>
>
> We have some projects which are dynamically creating VMs up to their
> quota. Under some circumstances, as cloud administrators, we would like
> these projects to shrink and make room for other higher priority work.
>
>
>
> We had in
On 16 Jun 2014 22:33, "Sean Dague" wrote:
>
> On 06/16/2014 04:33 AM, Thierry Carrez wrote:
> > Robert Collins wrote:
> >> [...]
> >> C - If we can't make it harder to get races in, perhaps we can make it
> >> easier to get races out. We have
On 16 Jun 2014 20:33, "Thierry Carrez" wrote:
>
> Robert Collins wrote:
> > [...]
> > C - If we can't make it harder to get races in, perhaps we can make it
> > easier to get races out. We have pretty solid emergent statistics from
> > every gate j
I think #2 is just as important to realize as #1. As such I think we
> need to get to the point where there are a relatively small number of
> configurations that Infra/QA support, and beyond that every job needs
> sponsors. And if the job success or # of uncateg
thing are delivered through e.g. galera in the DB layer.
-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
rainbow tables AIUI: if folk realise we have tokens exposed, they will
just use a botnet to build a table specifically targetting us.
-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
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> ___
>
t; OpenStack. It provides user-friendly Web interface for installations
> management, simplifying OpenStack installation up to a few clicks.
>
> Best Regards
> Leslie
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.op
On 23 May 2014 10:34, Salvatore Orlando wrote:
> As most of you probably know already, this is one of the topics discussed
> during the Juno summit [1].
> I would like to kick off the discussion in order to move towards a concrete
> design.
>
> Preamble: Considering the meat that's already on the
el situation is yet so I can't commit to being
> there on any dates, but I can certainly say which dates would work for
> me if I can make it.
>
> -Ben
>
>
> ___
> 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
uirks or workarounds.
If you are interested please do jump into #tripleo and chat to myself
or DerekH about how you can help out.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@list
ervasively through both Neutron and
OpenStack as a whole. Its baseline sanity for SQL usage
C) Implement more sophisticated schemas/update logic to
reduce/eliminate SELECT FOR UPDATE.
C seems like substantially more review and design work than B, while B
isn't &#
ct - the pros *and cons*. There's a certain
amount of hybrid vigour we get from supporting multiple backends - we
can scale in ways that a single backend might not; we can deploy in
environments that have hard corporate policies about 'the one true $X
is $Y'.
-Rob
--
Robert Collins
are intending to join, please, fill yourselves into this etherpad:
> https://etherpad.openstack.org/p/juno-midcycle-meetup
>
> Cheers
> -- Jarda
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.open
calable, low-maintenance way.
-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
ployed clouds which
>> we manage ourselves. We've had quite a few issues, mostly hardware
>> related, and some related to the fact that TripleO doesn't have HA yet,
>> so our CI clouds go down whenever our controllers go down.
>>
>> Anyway, Derek Higgins, Dan
ck-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.
ough:
> It would occur on a control node which removes the security benefits (I
> still wanted to make sure this point is made :)).
We should capture that nuance in the spec, and in the (related)
multiple-hypervisors-for-deployments spec where I pointed out similar
security concerns earlier t
ed in Ironic/Tempest/devstack or is a genuine Neutron
bug (though there is some reason to think its a Neutron bug based on
the kibana search I linked in the bug).
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev ma
is is a bit overkill given our current state, but I think for now its
> important we terminate external SSL earlier on: See ML thread linked
> above for reasoning.
If I read this correctly, you're arguing yourself back to the "User ->
hap
(I don't think we have any yet), but before I go through
> that, I wanted to make sure there wasn't a major disagreement.
>
> Thoughts?
>
> _______
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailma
On 18 May 2014 08:17, Miller, Mark M (EB SW Cloud - R&D - Corvallis)
wrote:
> We are considering the following connection chain:
>
>-> HAProxy -> stunnel ->OS services bound to
> 127.0.0.1
> Virtual IP server IP localhost
onward to Juno.
-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
endors to
> propose specs for the features they are working on once the initial work on
> the repo is complete (hopefully before end-of-week).
>
> Regards,
> Devananda
>
>
> [*] eg.:
> http://lists.openstack.org/pipermail/openstack-dev/2014-April/032753.html
>
> __
derivation logic to determine
their value
- if we need to set an option to work in test VMs where the
production value is different, we should guard it somehow - e.g. by
seeing if we're using VMs, or if the option is already present in the
environment file honour that value.
-Rob
--
Robert Co
On 2 May 2014 18:05, Robert Collins wrote:
> Thanks to Derek and the infra folk we now have a tripleo-specs repo - yay.
>
> https://review.openstack.org/#/c/91741/ needs to land before it will
> DTRT after cloning - but! - please add any outstanding unapproved
> blueprints ther
e same in both cases.
>>
>
> +1
I think outputs are good here, but indeed we should not be exposing
the control plane innards: thats what the virtual IP is for - lets
export that out of Heat, along with the port #, and thats it.
-Rob
--
Robert Collins
Distinguished Technologist
HP Co
Thanks to Derek and the infra folk we now have a tripleo-specs repo - yay.
https://review.openstack.org/#/c/91741/ needs to land before it will
DTRT after cloning - but! - please add any outstanding unapproved
blueprints there.
Thanks,
Rob
--
Robert Collins
Distinguished Technologist
HP
-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
Or have a check-mk.d directory and pull stuff on from there automatically
On 30 Apr 2014 04:03, "Gregory Haynes" wrote:
> > > Hi all,
> > >
> > > I have a patch in flight at the moment [0] to install check_mk server
> and compliment the already merged installation of check_mk agent [1] so my
> th
a lookup and work around this.
Since its trivial to write such a thunk, what benefit is there to your
users - e.g. TripleO/heat/nova not have it in keystone itself?
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
Ope
dilute the topic here a
bit)1,1,1
--
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
ck.org/cfp/details/203 Om Kumar Unreviewed
TripleO TripleO Roadmap
http://summit.openstack.org/cfp/details/347 Ryan Brady
Unreviewed
.5,
TripleO Documentation Improvement
http://summit.openstack.org/cfp/details/329 Ryan Brady
Unreviewed
1,1,1
Robert Collins
Distinguished Techn
On 22 April 2014 20:45, Thierry Carrez wrote:
> Robert Collins wrote:
>> I've pulled the summit talks into an etherpad
>> (https://etherpad.openstack.org/p/tripleo-icehouse-summit) - btw, who
>> can review these within the system itself?
>
> As the lead for the T
the global list of etherpads
- make any feedback changes reviewers may have requested.
Cheers,
Ro b
On 22 April 2014 12:01, Robert Collins wrote:
> I've pulled the summit talks into an etherpad
> (https://etherpad.openstack.org/p/tripleo-icehouse-summit) - btw, who
> can review these
at spectrum it lies :)
Its a modest reworking and synthesis of existing ideas, with some real
world operator experience, healthy paranoia about system reliability
and scaling concerns mixed in.
> BTW, it appears that the schedule you're suggesting involves assigning a
> bunch of
On 25 April 2014 04:49, Chris Armstrong wrote:
> On April 23, 2014 at 7:47:37 PM, Robert Collins (robe...@robertcollins.net)
> wrote:
>
> Hi, we've got this summit session planned -
> http://summit.openstack.org/cfp/details/428 which is really about
> https://etherp
changes we
>> need to make. Wherever we're at with the convergence step that was last
>> triggered can just be cancelled by the new one.
>
> Seems that we need a protocol for cancelling an operation then ...
I think Clint meant 'undoes' not 'cancels the in-progre
isting attempts to design
solutions which relied on keeping the basic internals of heat as-is
and just tweaking things - an approach we don't believe will work -
the issues arise from the current architecture, not the quality of the
code (which is fine).
Cheers,
Lifeless, Spamaps and Radix
--
ce time in
the summit is precious - things that are straight engineering are not
a particularly effective use of the time of a room with 30-80 people
in it.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev ma
work - I don't believe I've got the bandwidth to do
complete justice to both roles, so I'm going to focus on the PTL role
over the next cycle.
Naturally, I may well volunteer my time at the next TC vote, depending
on project status, bandwidth and so on :)
-Rob
--
Robert Co
On 16 April 2014 11:28, Michael Still wrote:
> On Wed, Apr 16, 2014 at 7:57 AM, Hugh O. Brock wrote:
>> On Wed, Apr 16, 2014 at 09:30:45AM +1200, Robert Collins wrote:
>
>>> Redhat offered to host the next TripleO midcycle meetup in Raleigh, I
>>> don't know if
This has been actioned. Welcome!
-Rob
On 8 April 2014 11:50, Robert Collins wrote:
> tl;dr: 3 more core members to propose:
> bnemec
> greghaynes
> jdon
>
>
> On 4 April 2014 08:55, Chris Jones wrote:
>> Hi
>>
>> +1 for your proposed -core changes.
On 16 April 2014 09:15, James Slagle wrote:
> On Tue, Apr 15, 2014 at 2:44 PM, Robert Collins
> wrote:
>> I've been watching the nova process, and I think its working out well
>> - it certainly addresses:
>> - making design work visible
>> - being able
if they have space for Nova & TripleO at once, but I'd love
to get more collaboration time betwixt Nova and TripleO. The TripleO
midcycle meetups are 'doing' meetings, not planning meetings - but
plenty of planning does still happen ;)
Date wise, how about before OSCON ? PyCon
ing we can just add docs to incubator, since thats already a
repository separate to our production code - what do folk think?
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.ope
merge.py.
>
> Hey Clint,
>
> Sorry for the confusion and any extra work this caused you. I missed that our
> new policy was not to land *any* TripleO heat template changes until your
> software config branch goes in. I usually try to keep up with the list but I
> missed th
x27;s thrilling to see all the effort folk have been
putting into this - I just showed it to one of our product folk here
and they really love it ;)
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
Ope
ron-dhcp agent can be configured as active/active.
>
> But l3-agent and metadata-agent still should be active/passive,
Why should the metadata-agent be active-passive?
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
os-apply-config to break hard this way,
than through bad metadata. I think I'm ok with the sentiment, but
nervous about impl.
-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
Summit time is here - please suggest sessions :)
-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
t; Historical data should go somewhere else.
+1. Fastest way to make an OLTP workload crawl is to mix it up with warehousing.
-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
We had a long chat about this in the meeting today.
we had rough consensus on the following path of action
- we'll put together a quick-but-effective config passthrough
mechanism, with a goal of landing it in the next few days
- it needs to handle tie and tht - we need a pass through vector for
day one of their deploy - so we need a way to:
- deliver a great out of the box experience
- let higher order configuration - cluster aware - be done well
- whilst also surfacing the plumbing as needed.
Right now we have no differentiation between plumbing exposure and
semantically modelled confi
On 8 April 2014 11:51, Dan Prince wrote:
>
>
> - Original Message -
>> From: "Robert Collins"
>> To: "OpenStack Development Mailing List"
>> Sent: Monday, April 7, 2014 4:00:30 PM
>> Subject: [openstack-dev] [TripleO] config options,
oom-to-improve issue vs
not-good-enough-for-core - to me it makes sense to propose him for
core too.
Jay's reviews are also very good and consistent, somewhere between
Greg and Ben in terms of bigger-context awareness - so another
definite +1 from me.
-Rob
--
Robert Collins
Distin
27;re having to override a default. If the option is really a
case of 1a) I'm not sure we want it configurable at all.
Thoughts?
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lis
elf pm address
- in the Nova Ironic driver add instance metadata with the pm address
(only) of the node
Then we can just glue the instance metadata field to the conductor config key.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
_
see under
33% of the code changes going on (we're doing about 10 commits
a day - twice as many since december - and hopefully not slowing down!)
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
nt experience feedback to the project we deploy
* expanding our coverage to deploy everything
* Migrating to Tuskar for everything but the deployment of the seed
Obviously, if you have questions please ask!
-Rob
--
Robert Collins
Distinguished Techno
if you any concerns about impacting deployments - please
run 'check experimental' before approving things ;)
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.o
.
There is not currently an Ironic based overcloud job; we may add one in future.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/m
bout we make a copy of the latest config for each project for
each series - e.g. trunk of everything, Icehouse of servers with trunk
of everything else, etc and make that easily acccessible?
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
ng multiple machines talking to one IPMI
device is a great way to exceed session limits and cause lockups.
These seem fundamental showstoppers to me.
-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
uld be fixed in stone.
And now - time for a loose vote - who (who is a tripleo core today)
supports / disagrees with this proposal - lets get some consensus
here.
I'm in favour, obviously :), though it is hard to put reviews ahead of
direct itch scratching, its the only way to scale the proje
details about devtest on openstack for now since I
> figured everyone else could add their thoughts in their own words.
I think it would be super useful if you could capture all the things
in one place - it will mean we don't need to chase folk up to ensure
their idea is present in the et
cloud, and in fact its better to run it from there than from
e.g. the seed, because otherwise the jenkins slave is idle, just
wasting all the ram it used to build images.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
OpenStac
_
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
I like this.
I also like much of the spread of ideas that came up - lets capture
them to an etherpad and link that from a bluepr
On 21 March 2014 12:18, Jay Pipes wrote:
> This is a very mature stance and well-written email. Thanks, Flavio and
> all of the Marconi team for having thick skin and responding to the
> various issues professionally.
+1
-Rob
--
Robert Collins
Distinguished Technologist
HP Conver
thing, so - sorry that I took time to send this note - please
do dive in and we'll get some consensus around the direction to take
things.
Cheers,
Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing lis
a fully equipped firing squad, a last cigarette and
> a blindfold.
> - Erik de Castro Lopo
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.o
t to make. I don't think Marconi is
dumb, but I sure don't understand why . Thank you!
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.open
a good reason.
https://review.openstack.org/#/c/74600/ might be a good reason.
-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
h a
horrid antipattern its been a standing joke in many organisations I've
been in - and yet we're preparing to graduate *exactly that* which is
frankly perplexing.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
OpenS
put into maintenance
mode, keep publishing it to the scheduler, but add an extra spec to it
that won't match any request automatically.
Then 'deploy X to a maintenance node machine' is simple nove boot with
a scheduler hint to explicitly choose that machine, and all the
regular machin
one or part of pbr?
pbr has significant issues with dependencies due to its installation
in the early bootstrap stage of setup.py. So, it will be in pbr.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev ma
On 18 March 2014 07:28, Jay Pipes wrote:
> On Mon, 2014-03-17 at 16:10 +1300, Robert Collins wrote:
> Hi Rob, thanks for the heads up.
>
> A number of us use pbr for outside-of-OpenStack projects, and have
> relied on it for things like proper package versioning using git tags.
o
'version' key in setup.cfg) untagged commits.
-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 17 March 2014 10:32, Steve Baker wrote:
> On 17/03/14 10:14, Robert Collins wrote:
>> On 17 March 2014 09:20, Steve Baker wrote:
>>
>>> It looks like the cert files you want to transfer are all ascii rather than
>>> binary, which is good as we have yet to
te? We include
an SSH key in ascii form already with no issue.
-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
eployments are. OTOH testing the micro-cloud that folk may start with
is also a really good idea
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.ope
gt;>> Internet.)
>>>
>> https://launchpad.net/testrepository is linked from pypi
>
>
> Ah, thanks. I looked at that page, but in my head I thought I had once seen
> a Git repo for it and I couldn't see a link from there... I never guessed
> that the upstrea
l process
is aimed at moving things from incubator into stable trees as they
mature. We'll be stabilising the interfaces in tripleo-heat-templates
and tripleo-image-elements somehow in future too - but we don't have
good answers to some aspects there yet.
BUT
We want to support members of th
This is a new repository to provide common code for tuskar and the
seed initialisation logic - the post heat completion initial
configuration of a cloud.
Cheers,
Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev
#x27;ll replace the motherboard.
That said, infra isn't spinning up nodes properly, but manual testing
brings up nodes just fine with plenty of network speed, so we're not
sure whats up.
-Rob
On 25 February 2014 13:08, Robert Collins wrote:
> Today we had an outage of the tripleo test
y to address concerns
> about a submitted patch is to provide a review for that patch.
+1000
> Everybody has a voice and the ability to participate, and the most effective
> way to do that is by thorough, timely and constructive code reviews.
+1000
-Rob
--
Robert Collins
.openstack.org/openstack/tripleo-heat-templates
> http://git.openstack.org/openstack/diskimage-builder
These:
> http://git.openstack.org/openstack/os-collect-config
> http://git.openstack.org/openstack/os-refresh-config
> http://git.openstack.org/openstack/os-apply-config
don
ations of all target DB platforms, so we do still need
to cater for this.
-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 27 February 2014 20:35, Robert Collins wrote:
'
> Checking new instance connectivity next.
DHCP is functional and no cloud-init errors, so we should be fully up.
-Rob
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
O
On 27 February 2014 15:55, Derek Higgins wrote:
> On 25/02/14 00:08, Robert Collins wrote:
>> Today we had an outage of the tripleo test cloud :(.
>>
>> tl;dr:
>> - we were down for 14 hours
>> - we don't know the fundamental cause
>> - infra were
Looking into it now.
On 27 Feb 2014 15:56, "Derek Higgins" wrote:
> On 25/02/14 00:08, Robert Collins wrote:
> > Today we had an outage of the tripleo test cloud :(.
> >
> > tl;dr:
> > - we were down for 14 hours
> > - we don't know the fundam
g weird questions in
#openstack-neutron.
But what are we meant to do? Nova etc are dead easy: nova-manage db
sync every time the code changes, done.
Neutron seems to do something special and different here, and it's not
documented from an ops perspective AFAICT - so - please help, cluebats
n
away from the keyboard at the time*.
And possibly a third:
- a way for openstack-infra admins to escalate to us in the event of
OMG things happening. Like, we send 1000 VMs all at once at their git
mirrors or something.
And with that lets open the door for ideas!
-Rob
--
Robert Collins
ng, and did not clear until we did a rolling restart of every
nova compute process.
https://bugs.launchpad.net/tripleo/+bug/1284356
Cheers,
Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@li
oblem, fix it sufficiently for CI (e.g. even
if we end up running a patched nova while nova review the patches
thats better than no CI).
-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 18 February 2014 04:30, Derek Higgins wrote:
> On 17/02/14 01:25, Robert Collins wrote:
>> Hi!
>>
>> The nascent tripleo-gate is now running on all tripleo repositories,
>> *and should pass*, but are not yet voting. They aren't voting because
>> we ca
On 18 February 2014 13:25, Robert Collins wrote:
> How do you put the code in? It's asking for a credit card no matter what I
> do..
>
NVM. Found the nicely styled small text in low contrast colour.
/me headdesks
--
Robert Collins
Distinguished Technologist
HP C
___
> 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
even if a provider can't be
contacted. The other is to have zuul timeout jobs that don't start at
all. Both should be small - < 1 day of dev for a cold start on the
project. Pure python.
-Rob
--
Robert Collins
Distinguished Technolo
601 - 700 of 1124 matches
Mail list logo
