s are supposed to be.
> >
> > I see a few changes:
> > * Allow external resource to depend on other resources
> > * Expose more port attributes
> > * Expose more subnet attributes
> >
> > If you can list the attributes you care about that'd be great
not TripleO UI specifically. Note that we will also need a 'reverse'
> Mistral workflow which is going to convert template yaml network_config
> into the input json format, so GUI can display current configuration to the
> user and let him change that.
>
> Liz has update
__
> 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
>
+1, glad to hear it.
--
Dan Sneddon | Senior Principal OpenS
On 04/20/2017 12:37 AM, Steven Hardy wrote:
> On Wed, Apr 19, 2017 at 02:51:28PM -0700, Dan Sneddon wrote:
>> On 04/13/2017 12:01 AM, Rabi Mishra wrote:
>>> On Thu, Apr 13, 2017 at 2:14 AM, Dan Sneddon >> <mailto:dsned...@redhat.com>> wrote:
>>>
>>
On 04/13/2017 12:01 AM, Rabi Mishra wrote:
> On Thu, Apr 13, 2017 at 2:14 AM, Dan Sneddon <mailto:dsned...@redhat.com>> wrote:
>
> On 04/12/2017 01:22 PM, Thomas Herve wrote:
> > On Wed, Apr 12, 2017 at 9:00 PM, Dan Sneddon <mailto:dsned...@redha
On 04/12/2017 01:22 PM, Thomas Herve wrote:
> On Wed, Apr 12, 2017 at 9:00 PM, Dan Sneddon wrote:
>> I'm implementing predictable control plane IPs for spine/leaf, and I'm
>> running into a problem implementing this in the TripleO Heat templates.
>>
>> I hav
ut this?
[1] - https://review.openstack.org/#/c/413278/
[2] -
https://docs.openstack.org/developer/heat/template_guide/hot_spec.html#intrinsic-functions
--
Dan Sneddon | Senior Principal Software Engineer
dsned...@re
hat would accomplish this?
--
Dan Sneddon | Senior Principal Software Engineer
dsned...@redhat.com | redhat.com/openstack
dsneddon:irc| @dxs:twitter
__
OpenStack Development Mailing List (not for usage qu
accentuate the ears (since
owls often have white tufts on their ears).
I whipped up a quick example of what I'm talking about, it's attached
(hopefully it will survive the mailing list).
[1] - https://www.google.com/search?q=owl+face&tbm=isch&tbo=u&source=univ
--
as a prototype?
I'll be at the PTG Tuesday through Friday morning. I'm looking forward
to having some conversations about this topic.
--
Dan Sneddon | Senior Principal OpenStack Engineer
dsned...@redhat.com | redhat.com/openstack
dsneddon:irc| @dxs:twitter
On 02/09/2
://blueprints.launchpad.net/tripleo/+spec/tripleo-routed-networks-ironic-inspector
[8] -
https://blueprints.launchpad.net/tripleo/+spec/tripleo-routed-networks-templates
--
Dan Sneddon | Senior Principal OpenStack Engineer
dsned...@redhat.com | redhat.com/openstack
dsneddon:irc| @dxs:twitter
uable. I would like to
> encourage them to keep doing more reviews in and out container bits.
>
> As usual, core members are welcome to vote on the changes.
>
> Thanks,
>
+1, thanks for all the work you did in the past, Jay!
--
Dan Sneddon | Senior Principal OpenS
help us move toward a consensus
approach.
[1] - https://review.openstack.org/#/c/409920
[2] - https://review.openstack.org/#/c/409921
--
Dan Sneddon | Senior Principal OpenStack Engineer
dsned...@redhat.com | redhat.com/openstack
dsneddon:irc| @dxs:twitter
On 12/08/2016 08:10 PM, Jason Rist wrote:
> On 12/08/2016 05:28 PM, Dan Sneddon wrote:
>> On 12/08/2016 06:05 AM, Jiri Tomasek wrote:
>>> Hi all,
>>>
>>> I've been investigating how to implement TripleO network configuration
>>> in TripleO UI. B
ince I wrote the patchset [1], but I would like to merge the
networker.yaml role and then can backport it prior to refactoring the
NIC configs. In general, though, I think we can limit the number of NIC
configs to one per physical topology, and then enable/disable interfaces,
VLANs, routes, etc. for
ion. If the controllers have more NICs than the
computes, then that requires a different base configuration.
So this would change the workflow slightly. You would first develop a
template that included all the possi
ing which networks to use where. Note that while it's easy
to conceptualize automatic template generation based on LLDP data
received from the switch, I also expect this to be pretty
error-prone. For instance, it may be difficult to detect which
interfaces should be part of a bo
ripleo-group/90
> [2]: https://review.openstack.org/#/c/352852/
>
>
> __
> 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/openstac
do for the
control plane, then it would be impossible to configure a system with
only 2 NICs in a fault-tolerant way.
Second, there will be a large percentage of users who already have a
shared br-ex that wish to upgrade. Do we tell them that due to an
architectural change, they now must redeplo
dea why running
"ifdown " followed by "ifup " doesn't stop the dhclient
process started by the udev rule? Or why this behavior appears to be
new to RHEL 7.3?
[1] - https://bugs.launchpad.net/tripleo/+bug/1640598
--
Dan Sneddon | Senior Principal OpenStack Engineer
dsn
d we are lucky to have him onboard.
> I believe he would be a great core reviewer on HA-related work and we
> expect his review stats to continue improving as his scope broadens
> over time.
>
> As usual, feedback is welcome and please vote for this proposal!
>
> Thanks,
>
While I appreciate the desire to have stylistically consistent logos, my eyes
don't perceive this logo as an owl. Hummingbird, maybe, or a sparrow or perhaps
a parrot, but I don't see an owl. The current logo is not easy to mistake for
another brand of fowl.
>> Dan Sn
On 10/19/2016 10:33 AM, 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.
>
> The Ironic Inspector dns
additional_inspection_iprange =
"172.20.2.0,172.20.2.100,172.20.2.120,255.255.255.0,172.20.2.254"
I would like some feedback about how to represent this data in a way
that it can be easily parsed by Puppet, while remaining readable. Any
suggestions would be very much appreciated.
[1]
wonder if we should endeavor to
test them in CI. I suppose that begs the question, if we are testing
those, then why not Contrail, etc.? I don't know where we draw the
line, but it seems that we might want to at least periodically test
deploying some other Neutron drivers via TripleO.
[1] - h
t for each service that UI expects to talk to (keystone, heat,
> ironic, mistral, swift, zaqar-websocket).
>
> Once those configuration changes were made, I had a very pleasant experience
> using the UI. It worked exactly as expected. I think this might be a viable
> option.
>
> T
h investigating.
>> Dan Sneddon | Principal OpenStack Engineer | dsned...@redhat.com
> On Sep 30, 2016, at 11:36 AM, Dan Sneddon wrote:
>
> I don't think we can rely on the Undercloud as an API proxy unless we address
> the lack of HA on the Undercloud.
>
> Wouldn
t sure where it stands.
>> Dan Sneddon | Principal OpenStack Engineer | dsned...@redhat.com
> On Sep 30, 2016, at 9:44 AM, Dan Trainor wrote:
>
> Hi -
>
> I re-read your email a few times and like a few of the things that I see, but
> I'd love some more
28 matches
Mail list logo
