15:01:02 <sc68cal> #startmeeting neutron_ipv6
15:01:03 <openstack> Meeting started Tue Oct  7 15:01:02 2014 UTC and is due to finish in 60 minutes.  The chair is sc68cal. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:07 <openstack> The meeting name has been set to 'neutron_ipv6'
15:01:25 <sc68cal> HenryG: ping
15:02:10 <sc68cal> I'm hoping we can figure out a way forward on updating ipv6 attributes AKA sometimes None means something other than "None" ;)
15:02:15 <HenryG> o/
15:03:18 <HenryG> I really can't see anything wrong with adding the None option.
15:03:25 <HenryG> It seems to work just fine.
15:03:53 <sc68cal> Agree - I just had to remember that sometimes None doesn't mean None lol
15:04:19 <HenryG> Break it into the two APIs: create and update
15:04:39 <HenryG> For create, None and NOT_SPECIFIED have the same effect.
15:05:42 <HenryG> For update, None means set the current mode to None/Null/NOT_SET, and NOT_SPECIFIED means don't change anything.
15:06:37 <sc68cal> It's possible the API layer changes the "None" value from python-neutronclient into ATTR_NOT_SPECIFIED
15:07:02 <sc68cal> but yeah basically we just look out for it in the method for updating subnets
15:07:20 <sc68cal> and delete the attributes for an existing subnet
15:07:21 <aveiga> HenryG: doesn't this cause a state conflict? If the user sets NOT_SPECIFIED on create, later changes it to something, then sets NOT_SPEFICIED on a n update later, it's inconsistent
15:07:39 <aveiga> from a user point of view, that is
15:07:56 <sc68cal> aveiga: the problem is the REST API is a little funky on how to delete attributes from an object
15:08:01 <aveiga> ah, ok
15:08:07 <sc68cal> so imagine you created a subnet with an ipv6 attr set
15:08:27 <sc68cal> then you wanted to delete the ipv6 attr, you need to send a JSON object with the ipv6 attr key present, with a value of "None"
15:08:47 <sc68cal> the API layer does some conversion into a value that it passes into the Neutron REST layer, ATTR_NOT_SPECIFIED
15:09:28 <aveiga> ok, as opposed to not requesting something, which would send a NOT_SPECIFIED over the API call, but would have no effect when actually updating the object?
15:09:57 <sc68cal> Basically, as long as we don't allow subnet objects to persist in the DB in such a way that the key for the ipv6 attributes exists, but has no value in it
15:10:17 <sc68cal> we should be ok, I think there is logic sprinked around that checks for the key in the dictionary, and assumes a value is present
15:10:20 <aveiga> ok, we can move on from this; don't hold the meeting up explaining things to me
15:10:57 <sc68cal> just worried about bugs popping up
15:12:03 <HenryG> What about the part where the None is converted to NOT_SPECIFIED? We need make sure that passing None in the API call clears the attribute in the subnet.
15:12:14 <HenryG> For update.
15:12:42 <sc68cal> agree
15:12:46 <HenryG> I'll check it with the client and report back.
15:13:25 <sc68cal> If I remember correctly - https://launchpad.net/bugs/1362966
15:13:26 <uvirtbot> Launchpad bug 1362966 in neutron "IPv6 two attributes cannot be set to None" [Medium,In progress]
15:13:49 <baoli> is it useful to allow update on them?
15:13:49 <sc68cal> we may need the change to constants.py to allow None as a valid value (ick.)
15:14:05 <sc68cal> so that when you do --action=clear on the CLI it'll go through
15:14:28 <sc68cal> as https://review.openstack.org/#/c/125328/7 does
15:15:11 <sc68cal> baoli: I think it is, just because all the other API objects allow you to update
15:15:40 <baoli> sc68cal: not all of them allow updates.
15:16:20 <sc68cal> baoli: oh? hmmmmmm
15:16:51 <HenryG> I believe amotoki was also asking about subnet updates
15:17:23 * sc68cal looks at resources.py
15:17:26 <baoli> for example, 'cidr' can't be updated
15:17:43 <sc68cal> baoli: ah! that's a great point
15:17:43 <baoli> it's attributes.py
15:17:58 <amotoki> I am not sure it is useful. I just wanted to point out that the current behavior is incomplete.
15:18:25 <sc68cal> We could make a case that similar to cidr attr, you shouldn't be able to change the v6 attrs after the fact
15:18:30 <amotoki> Setting allow_put to False is a good candiate.
15:18:37 <sc68cal> amotoki: agree
15:19:01 <sc68cal> I wouldn't be surprised if the stuff on the back-end like radvd and dnsmasq don't play nicely with updates for v6 attrs
15:19:17 <sc68cal> if you go from like stateful -> slaac
15:19:31 <sc68cal> no test coverage probably
15:20:00 <amotoki> As you may know, when we change enable_dhcp from True to False or vise versa, dhcp-agent implemetation does not treat it perfectly :-(
15:20:16 <HenryG> Does changing allow_put to False count as an API change?
15:20:47 <amotoki> it is API change but they appeared in juno first time.
15:20:54 <sc68cal> ^ +1
15:20:59 <amotoki> we can disable *now*
15:21:18 <HenryG> amotoki: I thought they were added in Icehouse?
15:21:26 <sc68cal> HenryG: added, but disabled
15:21:31 <sc68cal> err, hidden
15:21:36 <amotoki> HenryG: but tehy are hidden.
15:21:38 <HenryG> ah yes, sorry
15:22:27 <sc68cal> so - I like the idea of allow_put = False on the ipv6 attrs. Simple change, and prevents a lot of complexity from popping up
15:22:48 <HenryG> Sounds good to me.
15:23:00 <amotoki> +1 from me. I don't see much value to allow to update these attrs.
15:23:01 <HenryG> Then we don't need to allow None for now?
15:23:03 <sc68cal> (plus amotoki likes it, so that means quicker merge ;)
15:23:25 <sc68cal> HenryG: yes
15:23:31 <amotoki> we need to reach mestery if we have a consensus.
15:23:40 <baoli> +1
15:23:46 <sc68cal> +1
15:23:48 <baoli> followup cleanup may be needed
15:24:10 <amotoki> baoli: what kind of cleanup are needed? for Juno?
15:24:26 <baoli> some code are dealing with updates of those two modes
15:24:49 <HenryG> DocImpact: "Make sure you create your IPv6 subnet right, because you can't update it." :)
15:24:54 <amotoki> baoli: what you mean is to cleanup the dead code. right?
15:25:23 <baoli> amotoki, yes. if update is not allowed, then logic/code to deal with it should be removed
15:25:25 <sc68cal> the patch that sets allow_put will probably delete some tests in the neutron tree
15:25:38 <sc68cal> only thing we need to check is tempest, if there are any update scenarios
15:25:47 <sc68cal> I don't think there are, but there is a chance
15:26:00 <amotoki> one thing we need to consider is neutronclient subnet-update has --ipv6-ra/address-mode already.....
15:26:41 <sc68cal> amotoki: good point
15:26:57 <amotoki> but IMHO it can be acceptable if we have good error message.
15:27:04 <baoli> amothoki, in addition https://review.openstack.org/#/c/117799/13/neutron/db/db_base_plugin_v2.py deals with update
15:27:15 <amotoki> baoli: it can be cleanup later.
15:27:33 <baoli> amotoki: agree
15:28:56 <amotoki> I think it is better to escalate it to dev list and know if our consensus is a good direction or not. we seem to have a consensus to disable PUT.
15:29:10 <sc68cal> amotoki: agreed
15:29:23 <irina_povolotska> hi guys! I wonder if you know that information on neutron plugins is currently being updated in DriverLog and in OpenStack marketplace
15:30:01 <amotoki> irina_povolotska: this is not the neutron meeting but IPv6 meeting, so I believe it is not a right place to ask.
15:30:05 <sc68cal> who wants to start the thread on the ML
15:31:02 <amotoki> sc68cal: HenryG: can either of you send a mail? I can send tomorrow morning (roughly 8 hours after), but it is better to send soon.
15:31:07 <HenryG> sc68cal: I don't mind sending the email
15:31:30 <sc68cal> HenryG: sounds good
15:31:50 <amotoki> HenryG: thanks
15:31:56 <HenryG> Reasons for this decision are? ...
15:32:05 <HenryG> Avoiding complexity in the code
15:32:27 <HenryG> Not sure if radvd, dhcp, etc behave well on update
15:32:36 <HenryG> Anything else?
15:32:56 <sc68cal> <sarcasm>makes it easier to close all those bugs</sarcasm>
15:33:02 <sc68cal> as invalid ;)
15:33:11 <baoli> HenryG, I think the main reason is about its usefulness. If there is a good use case, then we should support update
15:33:30 <sc68cal> We can also make a case, similar to how cidr is not allowed to be updated
15:33:31 <amotoki> I think two points you listed + there is no much value for updating.
15:33:56 <HenryG> Thanks all, sounds like enough info for an email
15:34:13 <amotoki> plus incompleteness of the implementation of update support.
15:34:40 <amotoki> it is a good reason to disable them in the initial support in juno.
15:35:24 <HenryG> amotoki: got it, thanks
15:40:02 <HenryG> Is there a bug filed for ipv6_*_mode allow_put=False ?
15:40:23 <sc68cal> probably not. But we may want to instead link to existing reports
15:40:39 <sc68cal> patch that allows_put should have fixes bug #'s for the existing reports
15:41:34 <amotoki> sounds good to me. The bug report reveals the need to disable allow_put, so it works for me.
15:42:14 <sc68cal> 1363064, and 1362966 ?
15:42:21 <sc68cal> https://launchpad.net/bugs/1362966
15:42:23 <uvirtbot> Launchpad bug 1362966 in neutron "IPv6 two attributes cannot be set to None" [Medium,In progress]
15:42:41 <sc68cal> https://launchpad.net/bugs/1363064
15:42:42 <uvirtbot> Launchpad bug 1363064 in neutron "Cannot set only one of IPv6 attributes while second is None" [Low,In progress]
15:42:55 <HenryG> thanks, sounds appropriate
15:42:56 <sc68cal> ^ that one is also update related
15:43:20 <amotoki> agree both are related
15:44:50 <baoli> https://bugs.launchpad.net/python-neutronclient/+bug/1373417 on the CLI side
15:44:51 <uvirtbot> Launchpad bug 1373417 in python-neutronclient "can't update ipv6-ra-mode and ipv6-address-mode due to invalid ip version exception" [Undecided,In progress]
15:45:05 <sc68cal> baoli: good find
15:46:06 <sc68cal> HenryG: if you haven't send the e-mail, probably could link the transcript for this meeting too
15:46:14 <sc68cal> for background and in-depth discussion
15:46:40 <HenryG> sc68cal: OK
15:48:08 <sc68cal> Anything else to discuss today?
15:48:14 <sc68cal> otherwise I can give everyone back 10 mins
15:48:37 <john-davidge> I'd like to draw some attention to https://review.openstack.org/#/c/87987
15:48:53 <john-davidge> Seems to be in a pretty good state now, reviews would be appreciated :)
15:49:25 <sc68cal> john-davidge: thanks for the reminder - I see the piece I was looking for (randomness)
15:49:30 <sc68cal> so I'll +1 that :)
15:49:56 <john-davidge> sc68cal: Thanks, hope you like the implementation
15:50:35 <john-davidge> sc68cal: HenryG is to thank for the use of uuidgen!
15:51:06 <sc68cal> only thing that could trip up is if uuidgen isn't on fedora or another distro
15:52:17 <john-davidge> sc68cal: I believe it's already used elsewhere in devstack, so that would cause wider problems
15:52:41 <sc68cal> john-davidge: yep - good point, I see it used in the Ceph lib
15:52:54 <john-davidge> sc68cal: Was just about to point to that
15:53:14 <sc68cal> so looks like we're good! :)
15:53:28 <john-davidge> great :)
15:55:15 <sc68cal> anything else, in the last 5 minutes?
15:58:16 <sc68cal> OK everyone, excellent work today, a pleasure working with you all
15:58:22 <sc68cal> until next week!
15:58:24 <amotoki> thanks all!
15:58:28 <sc68cal> #endmeeting