Re: [openstack-dev] [ironic] New mascot design

[Miles Gould]

On 10/03/17 16:28, Heidi Joy Tretheway wrote:

Hi Ironic team,
Here’s an update on your project logo. Our illustrator tried to be as
true as possible to your original, while ensuring it matched the line
weight, color palette and style of the rest. Thanks for your patience as
we worked on this! Feel free to direct feedback to me; we really want to
get this right for you.


I like it!

Miles

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] OpenStack client default ironic API version

[Miles Gould]

On 07/03/17 12:14, Jim Rollenhagen wrote:

I'm also good with the standard deprecation period for this.


+1 to "standard deprecation period" - sorry, I'd misremembered what that 
was.


Miles

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] OpenStack client default ironic API version

[Miles Gould]

On 06/03/17 20:46, Mario Villaplana wrote:

We also still have yet to decide what a suitable deprecation period is
for this change, as far as I'm aware. Please respond to this email
with any suggestions on the deprecation period.


One cycle?

Miles

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] New mascot design

[Miles Gould]

On 01/02/17 21:38, Lucas Alvares Gomes wrote:

But, let me ask something, what the foundation really wants to achieve
with this ? Cause I think we are conflating two things here: A logo (or
brand) and a mascot.


I think this is an excellent point. The constraints on logos make a lot 
of sense *for logos*, but it'll be very hard to achieve something like 
Pixie Boots within them. Could we perhaps use *two* images for different 
contexts?


1) a stylized logo, matching the guidelines, for use in "official" 
settings and anywhere that it will be seen alongside other projects' logos;
2) our existing Pixie Boots mascot, for use in "unofficial" settings 
(laptop stickers, T-shirts, chatbots, The Bear Metal Adventures of Pixie 
Boots webcomic series*, etc, etc).


It'll be much easier to agree on image 1 if we don't reject every 
proposal for not capturing every nuance of image 2.


If that makes sense, I have a suggestion for the next iteration of the 
logo, if one is needed: take the head from logo version 3.0. AFAICT, 
that meets all the objections raised so far:


 - it's simple and logo-like,
 - it's not holding any man-made objects,
 - it's friendly,
 - it has heavy-metal facial markings,
 - it's not making any potentially-obscene gestures.

It doesn't look exactly like Pixie Boots, but if we can carry on using 
Pixie in unofficial contexts, that shouldn't be a problem.


Miles

* In which Pixie Boots, sysadmin by day and rock musician by night, 
solves a series of increasingly baffling deployment problems using 
AWESOME DRUM SOLOS.


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] New mascot design

[Miles Gould]

On 01/02/17 01:28, arkady.kanev...@dell.com wrote:

I think Russian already owns the bear.


AIUI, trademark law allows for use of the same mark by different 
entities provided they operate in different enough spheres to prevent 
confusion. Hence the long-running litigation between Apple Music and 
Apple Computer. So I think we'd be OK using a bear as well.


For the record, I'd -1 a spec proposing statehood for Ironic.

Miles

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] New mascot design

[Miles Gould]

On 02/02/17 16:55, Loo, Ruby wrote:

 I guess a 'peace sign' wouldn't work?


That also has several meanings:

https://en.wikipedia.org/wiki/V_sign

On the other hand, the palm-forward version has no offensive meanings 
that I can see (the offensive version is palm-backwards).


I like the proposed logo v3.0, but I could get behind a version 3.1 in 
which the bear was flashing a peace/victory sign.


Miles

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] Deep dive session about the UI - January 12

[Miles Gould]

On 13/12/16 14:07, Ana Krivokapic wrote:

If you'd like a calendar invite for this deep dive, email me and I'll
add you to the meeting invite.


Yes please!

Miles

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Exposing project team's metadata in README files

[Miles Gould]

On 25/11/16 17:12, Jeremy Stanley wrote:


It came down less to safety and more to the fact that if you force
cgit to present rendered content then you lose the ability to
reference the source code for the same files.


I don't think this is an insurmountable problem: it should be possible 
to allow users to switch between "code view" and "rendered view" for 
file-types that support rendering.


Miles

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [api]

[Miles Gould]

On 14/11/16 20:52, Ian Cordasco wrote:

not_in is nice and explicit while nin and out are a bit, more clever. I think 
we should avoid trying to be clever.


Agreed - I think not_in is more intelligible and guessable than the 
other suggestions.


Miles

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [mistral] Promoting Dougal Matthews to the core team

[Miles Gould]

On 09/11/16 07:34, Renat Akhmerov wrote:

Ok, thank you all!

Dougal, welcome to the core team! I’m hoping for fruitful collaboration
with you :)


Congratulations, Dougal!

Miles

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ironic][tempest][openwhisk] Notes from the Barcelona summit

[Miles Gould]

Capsule rec.juggling-style review
-

**High:** Impossible to pick out one moment in particular, but in
general it was getting to chat informally over dinner/drinks/climbing
with other Stackers.  Thanks everyone for making me feel welcome!
**Low:** Spending four hours unable to get the keys for our AirBnB on
Monday, after barely sleeping the night before.
**Goal:** Meet people on the Ironic team, and put faces to IRC nicks.
This was a success, and it was great to meet everyone IRL.
**Bane:** The way most of the coffee stations ran out within minutes.
Was the intention that only the coffee in the marketplace and the
developer lounge would be replenished throughout the day? If so, this
wasn't communicated to me.

Tuesday
===

Speed-mentoring
---
This was definitely worth getting up early for, and I am Not A Morning
Person. One concern: there were separate "technical" and "career"
tracks. A slight problem for those who are interested in both; but
also I noticed the "technical" track was heavily male-dominated and
the "career" track was heavily female-dominated. Not sure what that
says about us as an industry, but I doubt it's anything good.

Keynotes

These were fun. I was particularly impressed by Rosie Bolton's use of
"zettabyte": I'm pretty sure that's the first time I've heard that
term used in anger.

Coffee break

No coffee!

Design Summit 101
-
https://etherpad.openstack.org/p/ocata-design-summit-101
This was my first summit, so this session was really useful. Told me
what to expect and how to contribute effectively (which I hope I
managed to some extent).

Networking Approaches in a container world
--
(Antoni Segura Puimedon, Flavio Castelli, Neil Jerram)
https://www.youtube.com/watch?v=ePEXxbQ1fes
Gave a decent overview of the problem (providing logical networks
connecting ephemeral containers on different hosts), the two major
solutions (either tunnelling, or creating subnets for the containers
running on each host and using IP routing), the tradeoffs involved,
and which tools take which approach.

Baremetal Deployment work session
-
https://etherpad.openstack.org/p/BCN-ops-baremetal-deploy
I wasn't able to contribute anything, but it was interesting and
useful to hear what approaches people are using.

Climbing

https://etherpad.openstack.org/p/ocata-climb
The perfect conclusion to a tiring conference day! Huge thanks to
Chris Dent for organising this.

Wednesday
=

Serverless: How to Build an Event-Driven, Polyglot Serverless 
Microservices Framework on OpenStack (Animesh Singh)

--
https://www.youtube.com/watch?v=7yA38yiUxig
This was honestly pretty horrifying. 15vCPUs, 26GB RAM, and 192 GB
disk footprint per invocation/s, so you can run snippets of
JavaScript? See the video at 7:08 for where I get these figures - I'd
love to be told I've misunderstood.

Empowering Ironic with Redfish support (Bruno Cornec)
-
https://www.youtube.com/watch?v=KxRo5cRpj6k
Adding support to Ironic for talking to Redfish, a young but exciting
JSON/REST-based protocol for managing baremetal servers. Unfortunately
some crucial features are missing from the 1.0 release of the spec, so
we're already seeing incompatible vendor extensions: I asked a few
questions at the end about how we could avoid the nightmare scenario
described in http://esr.ibiblio.org/?p=801.

Ironic API Evolution work session
-
https://etherpad.openstack.org/p/ironic-ocata-summit-api-evolution
Fixing our API to make it more consistent, useful and
standards-compliant.  Devananda had already done a great job of
structuring this discussion, so it all went very smoothly, and it's
great to see patches already appearing.

Thursday


Ironic Work Session: Task framework
---
https://etherpad.openstack.org/p/ironic-ocata-summit-task-framework
I think we mostly managed to resist the temptation to spec out
something all-singing and all-dancing here.

Ironic Work Session: QA/CI
--
https://etherpad.openstack.org/p/ironic-ocata-summit-qa
I appear to have volunteered to help on splitting out our API tests
from our functional tests and to create a PoC for using property-based
unit tests, possibly using Hypothesis.

Tempest plugins roadmap
---
https://etherpad.openstack.org/p/ocata-qa-tempest-plugin-repos
Turns out the core purpose of Tempest is not what I'd thought. I'd
thought of it as a tool for end-to-end testing, for use in CI; the
project cores think of it as a standalone tool that can be used to
smoke-test an existing OpenStack cloud. Install OpenStack on your
data-center, via any means; install Tempest on your laptop; run the
one against the other. The "Tempest as 

Re: [openstack-dev] [tripleo][ironic][puppet] Spine/Leaf: Adding Multiple Subnets to ironic-inspector-dnsmasq

[Miles Gould]

On 19/10/16 18:33, Dan Sneddon wrote:

I am doing research to support the spec for TripleO deployment on
routed networks [1]. I would like some input on how to represent
multiple subnet ranges for the provisioning network in undercloud.conf.

[snip]

## inspector_dnsmasq_tftp.erb ##
port=0
interface=<%= @dnsmasq_interface %>
bind-interfaces
dhcp-range=<%= @dnsmasq_ip_range %>,29
dhcp-boot=pxelinux.0,localhost.localdomain,<%= @dnsmasq_local_ip %>
dhcp-sequential-ip



Just to note, there's no problem with this at the dnsmasq level: you can 
specify as many dhcp-range options as you like, one per IP range. 
There's no need to break the configuration up into multiple files to 
support this.



We could potentially represent this data as a JSON, or as a list of
strings.


I vote for JSON (or maybe YAML?) over creating our own ad-hoc string format.


String:
additional_inspection_ipranges =
"172.20.1.0,172.20.1.100,172.20.1.120,255.255.255.0,172.20.1.254;172.20.2.0,172.20.2.100,172.20.2.120,255.255.255.0,172.20.2.254"


If we're creating a string format, the obvious approach is to re-use the 
one dnsmasq uses, which is


[,|][,[,]][,]

If the DHCP server is directly connected to a given network, it can 
deduce the netmask by querying the interface configuration.


OTOH,

 - that doesn't specify gateway
 - I don't like the idea of directly pasting structured strings into 
configuration files without validating their structure, and the 
temptation to do that would be great.


Miles

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] indoor climbing break at summit?

[Miles Gould]

On 17/10/16 18:43, Chris Dent wrote:

On Mon, 17 Oct 2016, gordon chung wrote:


you forgot to add disclaimer how you broke every bone in your body a
while back.


\o/ Thanks for paying attention, you get a gold star. But actually
it was only three. And it was outside.

Maybe what you're really looking for here is: Climbing is dangerous. If
you choose to climb, it is at your own risk.


Or as the Union International des Associations d'Alpinisme puts it: 
"Climbing and mountaineering are activities with a danger of personal 
injury or death. Participants in these activities should be aware of and 
accept these risks and be responsible for their own actions and 
involvement".


Speaking of which: woo yeah! I'm totally up for this, schedule permitting.

Miles

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] running non-devstack jobs in Python projects aka "it works outside devstack"

[Miles Gould]

On 14/10/16 12:33, Sean Dague wrote:

I kind of wonder if that hints to a better model here instead of the
deployments running services from master. Instead running periodics and
moving forward reference hashes every day if tests pass, and not if they
fail. That would let deployment tools automatically move forward, quite
close to master, but not get tightly coupled into every change.


+1. This would also make debugging gate failures easier: when the only 
thing that has changed is the project under test (and not every other 
service it depends on), the source of the breakage is much more likely 
to be the patch being tested.


Miles

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] ironic-inspector-core team update

[Miles Gould]

On 26/09/16 10:24, Dmitry Tantsur wrote:

I suggest adding Milan Kovacik (milan or mkovacik on IRC) to the
ironic-inspector-core team. He's been pretty active on ironic-inspector
recently, doing meaningful reviews, and he's driving our HA work forward.

Please vote with +1/-1. If no objections are recorded, the change will
be in effect next Monday.


Do I get a vote? +1 if so :-)

Miles

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] Extending python-dracclient to fetch System/iDrac resources

[Miles Gould]

On 13/09/16 20:30, Anish Bhatt wrote:

Is parsing iDrac/System attributes differently from BIOS attributes the
correct approach here (this will also make it match racadm output), or
should I be changing all Attributes to be parsed the same way ?


"Parse everything the same way" sounds like the simpler and less brittle 
option; is there a good reason *not* to consider GroupID for BIOS 
attributes?


Miles

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] our mascot - input needed

[Miles Gould]

On 15/07/16 03:53, Britt Houser (bhouser) wrote:

Koala is the best by a long shot. These ideas are all total stretches:
  Bee on a honeycomb – Its kinda like the bee is orchestrating
containers of honey.


That sounds more like a honeypot ant to me:
https://en.wikipedia.org/wiki/Honeypot_ant
https://www.youtube.com/watch?v=5rwDdWBIXIg

I think Ironic has dibs on using a bear, but you're probably OK with a 
koala since they're really marsupials :-)


Miles

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] [ironic] Input types for scheduler filters

[Miles Gould]

On 08/07/16 15:22, Miles Gould wrote:

On 07/07/16 17:43, Miles Gould wrote:

Further evidence that this isn't the intended behaviour: if you remove
all the calls to str(), then the original tests still pass, but the
' e' (substring matching) one doesn't.


I've now proposed this as a patch:
https://review.openstack.org/#/c/339576/ Please review!


Status update on this: Ruby Loo found a place in nova where the 
thing-being-matched is cast to a string before matching:


https://github.com/openstack/nova/blob/90ec46c87fbf572805c7758377431e26c93622a4/nova/scheduler/filters/compute_capabilities_filter.py#L87

This means  will match substrings and not subsets; we talked 
about this in the nova-scheduler meeting and agreed it's a bug. I'll 
submit a patch to fix it in Nova.


Alexis Lee has submitted a patch to the oslo.utils version to enforce 
the type of the value being matched:


https://review.openstack.org/#/c/339596/

There's some discussion about whether this is the right approach, but 
the Oslo cores have made clear that without some type-enforcement the 
code won't be merged into Oslo.


If the matcher code can't be merged into Oslo, we may copy it directly 
into ironic-lib until it can be; understandably, there's some resistance 
to this idea.


https://review.openstack.org/#/c/334431/

Reviews on all the above would be much appreciated!

Miles

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] [ironic] Input types for scheduler filters

[Miles Gould]

On 07/07/16 17:43, Miles Gould wrote:

Further evidence that this isn't the intended behaviour: if you remove
all the calls to str(), then the original tests still pass, but the
' e' (substring matching) one doesn't.


I've now proposed this as a patch: 
https://review.openstack.org/#/c/339576/ Please review!


Miles

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] [ironic] Input types for scheduler filters

[Miles Gould]

Hi everyone,

tl;dr: the tests for the  operator in 
nova.scheduler.filters.extra_specs_ops do not test what it looks like 
they're meant to test. This is confusing us, and holding up work in 
Ironic. Does it match its arguments against a list of strings, or 
against a single string?


--

Over in Ironic, we need a more flexible language for specifying 
root-device hints, and we thought it would be a Good Thing to adopt the 
scheduler filter language used in Nova. There's already a review in 
progress to move that code into oslo.utils 
(https://review.openstack.org/#/c/308398) and another to clean it up 
with a well-defined formal grammar 
(https://review.openstack.org/#/c/313699/), so this ought to be an easy 
win. But! We're not sure that we've correctly understood the semantics 
of the language, which in turn means we can't tell if it's suitable for 
our use.


Here are two representative tests for the  operator:

def test_extra_specs_matches_one_with_op_allin(self):
values = ['aes', 'mmx', 'aux']
self._do_extra_specs_ops_test(
value=str(values),
req=' aes mmx',
matches=True)

def test_extra_specs_fails_with_op_allin(self):
values = ['aes', 'mmx', 'aux']
self._do_extra_specs_ops_test(
value=str(values),
req='  txt',
matches=False)

So it looks like  takes a list of strings, and matches against a 
`value` which is also a list of strings, and returns True iff every 
argument is in `value`. But look closer. Those tests actually check 
matching against str(values), which is the literal string "['aes', 
'mmx', 'aux']". This is also a valid Python collection, to which the 
Python `in` operator applies just fine, so what these tests actually 
check is if every argument string is a *substring* of str(values). This 
means that the following test passes:


def test_extra_specs_matches_all_with_op_allin(self):
values = ['aes', 'mmx', 'aux']
self._do_extra_specs_ops_test(
value=str(values),
req=' e',
matches=True)

[Don't believe me? See https://review.openstack.org/#/c/336094]

Is this the intended behaviour? When this is called as part of a real 
scheduler filter, is the list of values stringified before matching like 
this?


Further evidence that this isn't the intended behaviour: if you remove 
all the calls to str(), then the original tests still pass, but the 
' e' (substring matching) one doesn't.


So, is  meant to be doing substring matching? Or are the tests 
in error?


Thanks!
Miles

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic][infra][qa] Ironic grenade work nearly complete

[Miles Gould]

On 09/06/16 23:21, Jay Faulkner wrote:

There was some discussion about whether or not the Ironic grenade job
should be in the check pipeline (even as -nv) for grenade,


Not having this would mean that changes to grenade could silently break 
Ironic's CI, right? That sounds really bad.


Miles

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] State machines in Nova

[Miles Gould]

On 01/06/16 13:50, Andrew Laski wrote:

This is a great point. I think most people have an implicit assumption
that the state machine will be exposed to end users via the API. I would
like to avoid that for exactly the reason you've mentioned. Of course
we'll want to expose something to users but whatever that is should be
loosely coupled with the internal states that actually drive the system.


That would probably help, but think about how you'll handle things when 
you have to make changes to the client-visible representation :-)


Miles

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] State machines in Nova

[Miles Gould]

On 01/06/16 16:45, Joshua Harlow wrote:

Do u have any more details (perhaps an 'real-life' example that you can
walk us through) of this and how it played out. It'd be interesting to
hear (I believe it has happened a few times but I've never heard how it
was resolved or the details of it).


The most recent example was IIRC the proposed addition of an ADOPTING state:

https://review.openstack.org/#/c/275766/

Here's the log of the meeting where we argued about how to deal with it:

http://eavesdrop.openstack.org/meetings/ironic/2016/ironic.2016-05-16-17.00.log.html#l-66

Eventually we put it to a vote, and the "tell the client the truth, even 
if they're too old to handle it properly" side won.


Miles

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] State machines in Nova

[Miles Gould]

On 31/05/16 21:03, Timofei Durakov wrote:

there is blueprint[1] that was approved during Liberty and resubmitted
to Newton(with spec[2]).
The idea is to define state machines for operations as live-migration,
resize, etc. and to deal with them operation states.


+1 to introducing an explicit state machine - IME they make complex 
logic much easier to reason about. However, think carefully about how 
you'll make changes to that state machine later. In Ironic, this is an 
ongoing problem: every time we change the state machine, we have to 
decide whether to lie to older clients (and if so, what lie to tell 
them), or whether to present them with the truth (and if so, how badly 
they'll break). AIUI this would be a much smaller problem if we'd 
considered this possibility carefully at the beginning.


Miles

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Distributed Database

[Miles Gould]

On 02/05/16 18:43, Jay Pipes wrote:
This DB could be an RDBMS or Cassandra, depending on the deployer's 
preferences
AFAICT this would mean introducing and maintaining a layer that 
abstracts over RDBMSes and Cassandra. That's a big abstraction, over two 
quite different systems, and it would be hard to write code that 
performs well in both cases. If performance in this layer is critical, 
then pick whichever DB architecture handles the expected query load 
better and use that.


Miles

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] [ironic] Picking an official name for a subproject (ironic-inspector in this case)

[Miles Gould]

I also vote for baremetal-inspection - punning names are fun, but increase the 
amount of stuff new developers have to learn.

I'm totally in for the Peter Sellers marathon, though.

Miles

- Original Message -
> From: "Jay Pipes" 
> To: openstack-dev@lists.openstack.org
> Sent: Saturday, 5 December, 2015 2:53:17 PM
> Subject: Re: [openstack-dev] [all] [tc] [ironic] Picking an official name for 
> a subproject (ironic-inspector in this
> case)
> 
> On 12/04/2015 04:45 PM, Dmitry Tantsur wrote:
> > 1. "baremetalintrospection" - named after the process we
> > implement
> > 2. "baremetalinspector" - using our code name after the
> > official ironic project name.
> 
> baremetal-inspection is my vote.
> 
> I believe Pavlo will soon be proposing a hardware-composition service
> endpoint as well...
> 
> Best,
> -jay
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] [Ironic] Let's stop hijacking other projects' OSC namespaces

[Miles Gould]

- Original Message -
> From: "Lennart Regebro" 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Sent: Tuesday, 10 November, 2015 1:42:52 PM
> Subject: Re: [openstack-dev] [TripleO] [Ironic] Let's stop hijacking other 
> projects' OSC namespaces
> 
> These changes are fine to me.
> 
> I'm not so sure about the idea that we can't "hijack" other projects
> namespaces. If only ironic is allowed to use the prefix "baremetal",
> then the prefix should not have been "baremetal" in the first place,
> it should have been "ironic". Which of course means it would just be a
> replacement for the ironic client, making these whole namespaces
> pointless.

I thought the point of the new namespaces was to reduce cognitive load on users 
- "what's the command for doing things with baremetal nodes, again? Some pun on 
metals and 90s pop music - metallica? goldie? lithium? ironmaiden?"

Miles

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] Next meeting is November 9

[Miles Gould]

Thanks!

Miles

- Original Message -
From: "Dmitry Tantsur" <dtant...@redhat.com>
To: openstack-dev@lists.openstack.org
Sent: Thursday, 22 October, 2015 11:37:49 AM
Subject: Re: [openstack-dev] [ironic] Next meeting is November 9

On 10/22/2015 12:33 PM, Miles Gould wrote:
> I've just joined - what is the usual place and time?

Hi and welcome!

All the information you need you can find here: 
https://wiki.openstack.org/wiki/Meetings/Ironic

>
> Thanks,
> Miles
>
> - Original Message -
> From: "Beth Elwell" <e.r.elw...@gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)" 
> <openstack-dev@lists.openstack.org>
> Sent: Thursday, 22 October, 2015 8:33:03 AM
> Subject: Re: [openstack-dev] [ironic] Next meeting is November 9
>
> Hi Jim,
>
> I will be on holiday the week of the 9th November and so will be unable to 
> make that meeting. Work on the ironic UI will be posted in the sub team 
> report section and if anyone has any questions regarding it please shoot me 
> an email or ping me.
>
> Thanks!
> Beth
>
>> On 22 Oct 2015, at 01:58, Jim Rollenhagen <j...@jimrollenhagen.com> wrote:
>>
>> Hi folks,
>>
>> Since we'll all be at the summit next week, and presumably recovering
>> the following week, the next Ironic meeting will be on November 9, in
>> the usual place and time. See you there! :)
>>
>> // jim
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] Next meeting is November 9

[Miles Gould]

I've just joined - what is the usual place and time?

Thanks,
Miles

- Original Message -
From: "Beth Elwell" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Thursday, 22 October, 2015 8:33:03 AM
Subject: Re: [openstack-dev] [ironic] Next meeting is November 9

Hi Jim,

I will be on holiday the week of the 9th November and so will be unable to make 
that meeting. Work on the ironic UI will be posted in the sub team report 
section and if anyone has any questions regarding it please shoot me an email 
or ping me.

Thanks!
Beth

> On 22 Oct 2015, at 01:58, Jim Rollenhagen  wrote:
> 
> Hi folks,
> 
> Since we'll all be at the summit next week, and presumably recovering
> the following week, the next Ironic meeting will be on November 9, in
> the usual place and time. See you there! :)
> 
> // jim
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev