<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Thanks everyone for your responses...<br>
<br>
<div class="moz-cite-prefix">On 15/07/15 21:01, Doug Wiegley wrote:<br>
</div>
<blockquote
cite="mid:7EE54B93-E000-40FE-B432-DE1F7829AF33@parksidesoftware.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
That begins to looks like nova’s metadata tags and scheduler,
which is a valid use case. The underpinnings of flavors could do
this, but it’s not in the initial implementation.
<div class=""><br class="">
</div>
<div class="">doug</div>
<div class=""><br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Jul 15, 2015, at 12:38 PM, Kevin Benton
<<a moz-do-not-send="true"
href="mailto:blak111@gmail.com" class="">blak111@gmail.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">Wouldn't it be valid to assign
flavors to groups of provider networks? e.g. a tenant
wants to attach to a network that is wired up to a 40g
router so he/she chooses a network of the "fat pipe"
flavor.</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
<br>
Indeed.<br>
<br>
Otherwise, why does 'flavor:network' exist at all in the current
codebase?<br>
<br>
As the code currently stands, 'flavor:network' appears to be
consumed only by agent/linux/interface.py, with the logic that if
the interface_driver setting is set to MetaInterfaceDriver, the
interface driver class that is actually used for a particular
network will be derived by using the network's 'flavor:network'
value as a lookup key in the dict specified by the
meta_flavor_driver_mappings setting.<br>
<br>
Is that an intended part of the flavors design?<br>
<br>
I hope it doesn't sound like I'm just complaining! My reason for
asking these questions is that I'm working at
<a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/198439/">https://review.openstack.org/#/c/198439/</a> on a type of network that
works through routing on each compute host instead of bridging, and
two of the consequences of that are that<br>
<br>
(1) there will not be L2 broadcast connectivity between the
instances attached to such a network, whereas there would be with
all existing Neutron network types<br>
<br>
(2) the DHCP agent needs some changes to provide DHCP service on
unbridged TAP interfaces.<br>
<br>
Probably best here not to worry too much about the details. But, at
a high level:<br>
<br>
- there is an aspect of the network's behavior that needs to be
portrayed in the UI, so that tenants/projects can know when it is
appropriate to attach instances to that network<br>
<br>
- there is an aspect of the network's implementation that the DHCP
agent needs to be aware of, so that it can adjust accordingly.<br>
<br>
I believe the flavor:network 'works', for these purposes, in the
senses that it is portrayed in the UI, and that it is available to
software components such as the DHCP agent. So I was wondering
whether 'flavor:network' would be the correct location in principle
for a value identifying this kind of network, according to the
intention of the flavors enhancement.<br>
<br>
<br>
<blockquote
cite="mid:7EE54B93-E000-40FE-B432-DE1F7829AF33@parksidesoftware.com"
type="cite">
<div class="">
<div>
<blockquote type="cite" class="">
<div class="">
<div class="gmail_extra"><br class="">
<div class="gmail_quote">On Wed, Jul 15, 2015 at 10:40
AM, Madhusudhan Kandadai <span dir="ltr" class=""><<a
moz-do-not-send="true"
href="mailto:madhusudhan.openstack@gmail.com"
target="_blank" class="">madhusudhan.openstack@gmail.com</a>></span>
wrote:<br class="">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr" class=""><br class="">
<div class="gmail_extra"><br class="">
<div class="gmail_quote"><span class="">On Wed,
Jul 15, 2015 at 9:25 AM, Kyle Mestery <span
dir="ltr" class=""><<a
moz-do-not-send="true"
href="mailto:mestery@mestery.com"
target="_blank" class="">mestery@mestery.com</a>></span>
wrote:<br class="">
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div dir="ltr" class="">
<div class="gmail_extra">
<div class="gmail_quote"><span
class="">On Wed, Jul 15, 2015 at
10:54 AM, Neil Jerram <span
dir="ltr" class=""><<a
moz-do-not-send="true"
href="mailto:Neil.Jerram@metaswitch.com"
target="_blank" class="">Neil.Jerram@metaswitch.com</a>></span>
wrote:<br class="">
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">I've
been reading available docs
about the forthcoming Neutron
flavors framework, and am not
yet sure I understand what it
means for a network.<br class="">
<br class="">
</blockquote>
<div class=""><br class="">
</div>
</span>
<div class="">In reality, this is
envisioned more for service
plugins (e.g. flavors of LBaaS,
VPNaaS, and FWaaS) than core
neutron resources.</div>
</div>
</div>
</div>
</blockquote>
</span>
<div class="">Yes. Right put. This is for
service plugins and its part of extensions
than core network resources// <br class="">
</div>
<span class="">
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div dir="ltr" class="">
<div class="gmail_extra">
<div class="gmail_quote">
<div class=""> <br class="">
</div>
<span class="">
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
Is it a way for an admin to
provide a particular kind of
network, and then for a tenant
to know what they're attaching
their VMs to?<br class="">
<br class="">
</blockquote>
<div class=""><br class="">
</div>
</span>
<div class="">I'll defer to Madhu
who is implementing this, but I
don't believe that's the intention
at all.<br class="">
</div>
</div>
</div>
</div>
</blockquote>
</span>
<div class="">Currently, an admin will be able
to assign particular flavors, unfortunately,
this is not going to be tenant specific
flavors.</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
<br>
To be clear - I wasn't suggesting or asking for tenant-specific
flavors. I only meant that a tenant might choose which network to
attach a particular set of VMs to, depending on the flavors of the
available networks. (E.g. as in Kevin's example above.)<br>
<br>
<blockquote
cite="mid:7EE54B93-E000-40FE-B432-DE1F7829AF33@parksidesoftware.com"
type="cite">
<div class="">
<div>
<blockquote type="cite" class="">
<div class="">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr" class="">
<div class="gmail_extra">
<div class="gmail_quote">
<div class=""> As you might have seen in the
review, we are just using tenant_id to
bypass the keystone checks implemented in
base.py and it is not stored in the db as
well. It is something to do in the future
and documented the same in the blueprint.</div>
<span class="">
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div dir="ltr" class="">
<div class="gmail_extra">
<div class="gmail_quote">
<div class=""> <br class="">
</div>
<span class="">
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
How does it differ from
provider:network-type? (I
guess, because the latter is
supposed to be for
implementation consumption only
- but is that correct?)<br
class="">
<br class="">
</blockquote>
<div class=""><br class="">
</div>
</span>
<div class="">Flavors are created
and curated by operators, and
consumed by API users.<br class="">
</div>
</div>
</div>
</div>
</blockquote>
</span>
<div class="">+1<br class="">
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
<br>
Many thanks,<br>
Neil<br>
<br>
</body>
</html>