<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> --- scaling down Ironic into a tool useful at smaller scale (that a tool <br>
> like cobbler has a strong hold on today)<br>
<br>
Not clear from the etherpad: is it a question of scale or UX? I'm not <br>
sure a Bifrost installation is much larger than MaaS, etc (although we <br>
can always optimize it further, e.g. add sqlite as an option).<br>
<br></blockquote><div><br></div><div>Yes to all? It's more that this is a space that we have very little market penetration into, and I'd like to solve it. I think there's going to need to be a nexus of documentation, simplification, and fighting back against false perceptions to make progress here, but it's worthwhile because of the size of the potential growth.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The etherpad mentions "Easy enough", and ease of use is definitely the <br>
field where we Ironic leaves a lot to be desired. Possibilities that <br>
come to mind:<br>
1) My "deployment API" proposal,<br>
2) Adding a strict schema to our API and clean up confusing JSON fields,<br>
3) An image building service,<br>
4) The already mentioned network management,<br>
5) More high-level API actions/workflows.<br>
<br></blockquote><div><br></div><div>These are all really good ideas that go in the direction I was thinking :).</div><div><br></div><div>-</div><div>Jay Faulkner</div><div>Ironic PTL <br></div></div></div>