16:00:21 <bauzas> #startmeeting nova
16:00:21 <opendevmeet> Meeting started Tue Jul 19 16:00:21 2022 UTC and is due to finish in 60 minutes.  The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:21 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:21 <opendevmeet> The meeting name has been set to 'nova'
16:00:25 <bauzas> hello everyone
16:00:33 <bauzas> #link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting
16:00:53 * bauzas is currently trampled by internal issues with vgpus but I'll chair this meeting
16:01:08 <bauzas> who's around ?
16:01:15 <gibi> o/
16:01:22 <elodilles> o/
16:01:25 <bahnwaerter> o/
16:01:45 <dansmith> o/
16:02:02 <Uggla> o/
16:02:36 <bauzas> ok, we can start
16:02:57 <bauzas> #topic Bugs (stuck/critical)
16:03:05 <bauzas> #info No Critical bug
16:03:30 <bauzas> #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New 10 new untriaged bugs (-1 since the last meeting)
16:03:41 <bauzas> Uggla: thanks for helping on this
16:03:45 <bauzas> any bug to point out ?
16:04:46 <bauzas> mmmm, crickets
16:04:55 <bauzas> #link https://storyboard.openstack.org/#!/project/openstack/placement 27 open stories (+0 since the last meeting) in Storyboard for Placement
16:05:06 <bauzas> #info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster
16:05:11 <bauzas> #info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster
16:05:20 <bauzas> #link https://storyboard.openstack.org/#!/project/openstack/placement 27 open stories (+0 since the last meeting) in Storyboard for Placement
16:05:37 <bauzas> sean-k-mooney: do you have some time for looking at bugs this week ?
16:07:55 <bauzas> mmm, I'll discuss with sean-k-mooney later to know if he can
16:08:02 <bauzas> if not, I'll be the owner for this week
16:08:17 <bauzas> #topic Gate status
16:08:25 <bauzas> #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs
16:08:30 <sean-k-mooney> i can make it
16:08:35 <sean-k-mooney> i proably dont but i will
16:08:39 <bauzas> sean-k-mooney: thanks, very much
16:08:49 <bauzas> sean-k-mooney: again, this is not a priority
16:08:55 <bauzas> do it as you can
16:09:23 <bauzas> the number of open bugs is pretty low at this time, which is cool, kudos to the team
16:09:30 <sean-k-mooney> its fine ill keep an eye on them
16:09:33 <bauzas> s/open/new
16:09:40 <bauzas> #link https://zuul.openstack.org/builds?project=openstack%2Fplacement&pipeline=periodic-weekly Placement periodic job status
16:09:46 <bauzas> a new check :
16:09:52 <bauzas> #link https://zuul.openstack.org/builds?job_name=tempest-integrated-compute-centos-9-stream&project=openstack%2Fnova&pipeline=periodic-weekly&skip=0 Centos 9 Stream periodic job status
16:10:19 <bauzas> sean-k-mooney: didn't had time to see whether you proposed a tempest patch for removing c9s from check and gate ?
16:10:34 <dansmith> isn't there some way to see previous periodic runs too?
16:10:42 <sean-k-mooney> bauzas: yes i did
16:10:44 <dansmith> so we can see that it's passed N times in a row?
16:10:45 <sean-k-mooney> dansmith: yes
16:10:53 <dansmith> or has this only run once?
16:10:54 <sean-k-mooney> dansmith: i can see if i can get that
16:11:08 <bauzas> dansmith: https://zuul.openstack.org/builds?job_name=tempest-integrated-compute-centos-9-stream&project=openstack%2Fnova&skip=0
16:11:11 <dansmith> sean-k-mooney: not important now, just wanted to make sure we don't need to build a thing
16:11:11 <sean-k-mooney> i think you can filter the build by pipeline and proejct
16:11:24 <sean-k-mooney> ya basically ^
16:11:37 <bauzas> dansmith: as you see, for the moment, we're still testing c9s in check and gate due to a tempest template
16:11:39 <dansmith> yeah but that only shows one periodic run, is that because it has only run once yet?
16:11:44 <bauzas> dansmith: correct
16:11:47 <dansmith> gtotcha
16:12:03 <bauzas> we could also check experiment if we want
16:12:13 <sean-k-mooney> https://review.opendev.org/c/openstack/tempest/+/850242
16:12:16 <bauzas> ta
16:12:22 <sean-k-mooney> that is the tempest template update patch ^
16:12:28 <dansmith> ack
16:12:46 <bauzas> #link https://review.opendev.org/c/openstack/tempest/+/850242 removing Centos 9 stream jobs from default Tempest template
16:13:10 <bauzas> #link https://zuul.opendev.org/t/openstack/builds?job_name=nova-emulation&pipeline=periodic-weekly&skip=0 Emulation periodic job runs
16:13:18 <bauzas> #info Please look at the gate failures and file a bug report with the gate-failure tag.
16:13:25 <bauzas> #info STOP DOING BLIND RECHECKS aka. 'recheck' https://docs.openstack.org/project-team-guide/testing.html#how-to-handle-test-failures
16:13:30 <bauzas> that's it
16:13:32 <bauzas> moving on
16:13:40 <bauzas> #topic Release Planning
16:13:48 <bauzas> #link https://releases.openstack.org/zed/schedule.html
16:13:55 <bauzas> #info Zed-2 was last week
16:14:02 <bauzas> #info Specs are no longer accepted
16:14:23 <bauzas> #link https://blueprints.launchpad.net/nova/zed current blueprints open for the zed timeframe
16:14:41 <bauzas> 13 bps
16:14:45 <bauzas> less than in Yoga
16:14:54 <bauzas> we could have one more
16:15:06 <bauzas> but this will be discussed in the open discussion
16:15:38 <bauzas> oh, I forgot to prepare an etherpad, stupid me
16:16:05 <bauzas> give me a second, I'd like to ask our API microversion proposers to ask for a specific microversion
16:16:19 <bauzas> instead of all of them rushing into 2.92
16:16:22 <bauzas> 2.91
16:17:48 <bauzas> there it is
16:18:05 <bauzas> #link https://etherpad.opendev.org/p/nova-zed-microversions-plan Etherpad for a microversion use query
16:18:24 <bauzas> fwiw, I left 2.91 for https://review.opendev.org/c/openstack/nova/+/845897
16:18:40 <bauzas> and https://review.opendev.org/c/openstack/nova/+/849133 is now ready for 2.92
16:19:01 <bauzas> the latter will require a very small merge conflict resolution due to the api docs
16:19:24 <bauzas> but as you see, nothing was preventing me to use the 2.92 microversion even if 2.91 wasn't merged
16:19:46 <bauzas> that's why I propose our different change owners to ask for a microversion
16:20:34 <gibi> you will have a bit more than a single conflict on the api doc but yes hopefully the conflict will be small
16:20:36 <bauzas> I'll send an email tomorrow explaining about this
16:20:42 <bauzas> gibi: I tested it
16:20:50 <bauzas> gibi: 4 files were conflicting
16:20:53 <gibi> I expect a conflict on https://review.opendev.org/c/openstack/nova/+/849133/5/doc/api_samples/versions/v21-version-get-resp.json
16:21:04 <bauzas> yup, this one and the root v2
16:21:15 <bauzas> plus the rest api microversions list doc
16:21:21 <bauzas> and I can't remember the last one
16:21:23 <gibi> and on the api_version_request.py
16:21:25 <bauzas> but easy conflicts
16:21:50 <bauzas> could be harder to resolve if two changes are touching the same API resource
16:22:01 <bauzas> but let's not overcomplicate this
16:22:01 <Uggla> fyi I have just reserved 2.93 for virtiofs
16:22:28 <bauzas> Uggla: then prepare your API change to use the 2.93 microversion, this should work like mine
16:22:31 <gibi> bauzas: sure
16:23:44 <bauzas> tbc, we reserve the right to flip the microversions
16:23:50 <Uggla> need to review because I bet on 2.92.
16:23:53 <bauzas> depending on the state of the review
16:24:05 <bauzas> we had runways before
16:24:17 <bauzas> take it as a unformal runway for asking reviews
16:24:56 <bauzas> either way, I'll send an email explaining the rules
16:25:15 <bauzas> I don't want an overcomplicated process
16:25:29 <bauzas> this is just a way to prevent people doing frequent rebases
16:26:07 <bauzas> but the smaller microversion you ask, the higher you need to be reviewed hence be present
16:26:35 <bauzas> I just don't want us to wait for new revisions that could stale other changes
16:27:03 <bauzas> so I'll just say that we're free to drop some change from the microversion number
16:27:32 <bauzas> hope you folks don't disagree with this stupid plan
16:28:18 <gibi> with the amount of folks pushing for a microversion right now I don't see trouble
16:28:30 <Uggla> sounds good
16:28:32 <bauzas> well, I see 5 different patches
16:28:34 <bauzas> at leasty
16:29:00 <bauzas> anyway, moving on
16:29:02 <gibi> personally I would not bet on current+3 or higher to be ordered
16:29:18 <bauzas> #action bauzas to clarify the game rules of the etherpad in a later email tomorrow
16:29:19 <gibi> but having a c+1 and c+2 ordered make sens
16:29:21 <gibi> e
16:29:29 <bauzas> gibi: that's a reasonable point
16:29:36 <bauzas> I could remove 2.95 and newer
16:29:55 <bauzas> moving on
16:29:57 <bauzas> #topic Review priorities
16:29:57 <gibi> and also if you are not ready for review then please don't allocate a microversion :)
16:30:07 <bauzas> gibi: that's the game rule
16:30:14 <gibi> coolio
16:30:28 <bauzas> and if you are on vacations for 4 weeks, don't ask for the next microversion
16:30:49 <bauzas> or ask the next one, provided your patch can be reviewed before you leave
16:30:51 <bauzas> :)
16:30:56 <gibi> :)
16:31:08 <bahnwaerter> :)
16:31:28 * bauzas of course won't take 4 weeks off
16:31:33 <bauzas> only 3.5
16:31:51 <bauzas> #topic Review priorities
16:32:05 <bauzas> #link https://review.opendev.org/q/status:open+(project:openstack/nova+OR+project:openstack/placement+OR+project:openstack/os-traits+OR+project:openstack/os-resource-classes+OR+project:openstack/os-vif+OR+project:openstack/python-novaclient+OR+project:openstack/osc-placement)+label:Review-Priority%252B1
16:32:16 <bauzas> huzzah
16:32:21 <bauzas> #link https://review.opendev.org/c/openstack/project-config/+/837595 is merged
16:32:51 <bauzas> #link https://docs.openstack.org/nova/latest/contributor/process.html#what-the-review-priority-label-in-gerrit-are-use-for explains now the new gerrit flag and how to use it
16:33:21 <gibi> would be interesting to see how many +1 will appeare on this list from now
16:33:53 <dansmith> I friggin hate the RP label btw
16:33:56 <bauzas> at least two from sean-k-mooney :)
16:34:11 <gibi> bauzas: btw you need to update your query to show both +1 and +2
16:34:15 <dansmith> I keep RP+2ing patches and people ask a week later why I didn't CR+2 them :/
16:34:30 <bauzas> dansmith: point them doc
16:34:31 <sean-k-mooney> they were proably form before the update
16:34:43 <bauzas> gibi: yeah I need to modify it
16:34:52 <dansmith> bauzas: no, I mean *I* do the wrong thing because I go looking for the +2 button to click and choose the wrong one
16:35:04 <sean-k-mooney> yes they were bot form before the cahnge merged
16:35:09 <dansmith> I wish RP could be a different scale like -A +B +C
16:35:11 <sean-k-mooney> but plese do look at them
16:35:21 <sean-k-mooney> dansmith: it can be
16:35:25 <gibi> dansmith: valid point, can we change it from +2 to +B?
16:35:34 <bauzas> dansmith: ah I get your point
16:35:35 <dansmith> if we can choose anything,
16:35:38 <bauzas> it's confusing indeed
16:35:42 <sean-k-mooney> i am pretty sure it does not have to be a number
16:35:47 <dansmith> could we make it -NotYet, +Prio, +HighPrio ?
16:35:49 <bauzas> I don't know, we need to look at gerrit acls
16:36:06 <dansmith> or -Low, +Med, +High
16:36:06 <sean-k-mooney> i can check but this si just a cutom lable
16:36:24 <dansmith> don't do it just for me, but just relating my frustration with it on the glance side
16:36:24 <bauzas> dansmith: man, we got this https://review.opendev.org/c/openstack/project-config/+/837595 open for a while, you know your very good comment would have been more than appreciated then ? :D
16:36:46 <bauzas> anyway, it took us 6 months to get it
16:36:50 <dansmith> bauzas: sorry, but it has taken actual experience to realize it's annoying
16:37:02 <bauzas> I'm pretty sure we can take one month more to find if we can change the acls and to get it merged :p
16:37:08 <sean-k-mooney> bauzas: well thats just ebcause we didnt agree on what it shoudl be
16:37:13 <sean-k-mooney> if we can set a custom value
16:37:15 <bauzas> sean-k-mooney: not exactly
16:37:21 <sean-k-mooney> and we want too we can get it updated quickly
16:37:30 <dansmith> I will help push for reviews on a change if you want to do it
16:37:33 <bauzas> sean-k-mooney: it took us nearly a cycle to agree and then nearly a midcycle to get it merged
16:37:39 <dansmith> again, not trying to mess anything up, just conveying my experience
16:37:47 <bauzas> dansmith: your comment is legit
16:37:57 <sean-k-mooney> bauzas: thats just because i had asked them to wait until i went back to them
16:37:58 <bauzas> and I don't want contributors to mess this up
16:38:18 <gibi> I would go for +P (contributor review promise) +CP (core review promise)
16:38:25 <bauzas> someone thinking he would +1 a patch and instead saying "yay, I'm committed on reviewing it soon"
16:38:30 <dansmith> is that what you meant by +1 +2? :)
16:38:34 <dansmith> if so, the labels would be much more useful
16:38:42 <bauzas> yup
16:38:51 <sean-k-mooney> https://gerrit-review.googlesource.com/Documentation/config-labels.html#label_value
16:38:53 <bauzas> we'll figure it out
16:38:58 <sean-k-mooney> so it might need to be an int
16:39:39 <sean-k-mooney> the name can be anything we want
16:40:10 <sean-k-mooney> we can proably move on and confrim outside the meeting
16:40:14 <dansmith> ++
16:40:23 <gibi> ack
16:40:34 <bauzas> ++
16:41:19 <bauzas> we have someone having added https://review.opendev.org/c/openstack/nova-specs/+/816542 to the agenda
16:41:44 <bauzas> Spec for modifiable user_data was accepted / merged, but implementations are still pending final review / merge
16:41:57 <bauzas> so I guess he's raising our attention to :
16:42:15 <bauzas> #link https://review.opendev.org/c/openstack/nova/+/816157 server implementation
16:42:19 <bauzas> #link https://review.opendev.org/c/openstack/python-novaclient/+/816158 novaclient
16:42:25 <bauzas> #link https://review.opendev.org/c/openstack/python-openstackclient/+/847792 openstackclient
16:42:28 <sean-k-mooney> yep i skimmed that
16:42:28 <bauzas> #link https://review.opendev.org/c/openstack/python-novaclient/+/816158 novaclient
16:42:40 <bauzas> this is one of the API changes we have
16:42:46 <bauzas> 2.94 ?
16:43:14 <sean-k-mooney> im not sure if its reday to merge but its an api change yes
16:43:29 <bauzas> I'll add it to the etherpad
16:44:26 <bauzas> moving on
16:44:35 <bauzas> #topic Stable Branches
16:44:40 <bauzas> elodilles: are you around ?
16:44:42 <elodilles> yes
16:44:47 <elodilles> #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci
16:44:59 <elodilles> #info stable/train is blocked, fix exists but hasn't merged yet due to intermittent failures + now nova-grenade-multinode & nova-live-migration started to fail @ devstack 'create' phase
16:45:24 <elodilles> so train is now 'more' broken
16:46:00 <elodilles> i could not reproduce the devstack issue locally yet
16:46:08 <bauzas> looks like the French SNCF rail
16:46:16 <elodilles> :)
16:47:18 <elodilles> anyway, i'll try to look into the issue, but any hint is appreciated
16:48:27 <elodilles> (i've added some details to the nova-stable-branch-ci, but haven't created a bug yet)
16:48:54 <bauzas> elodilles: honesly, I'm under the water as I speak
16:49:28 <elodilles> bauzas: ok, no problem, it's just a heads up for everyone who is interested in train branch :)
16:49:49 <bauzas> *some* may be interested
16:50:14 <elodilles> and that's it about stable branches from me i think
16:50:53 * gibi more and more feels we don't have the bandwidth to maintain stable/train
16:52:01 <bauzas> unfortunately, let's move on, then
16:52:15 <bauzas> #topic Open discussion
16:52:21 <bauzas> (sean) https://review.opendev.org/c/openstack/nova-specs/+/849488 spec freeze exception for spice compression
16:52:38 <bauzas> so yeah I wrote we could discuss this now
16:52:48 <bauzas> to see whether we punt it for Zed or we accept it
16:53:10 <bauzas> anyone having opinions about it ?
16:53:15 <bauzas> tbh, I'm meh to it
16:53:35 <bauzas> trying to honestly balance the risks vs. the benefits
16:53:54 <sean-k-mooney> risk shoudl be small since this is not user faceing
16:53:59 <yoctozepto> o/
16:54:06 <sean-k-mooney> there is no api impact to this
16:54:17 <bauzas> this is configurable, right?
16:54:24 <yoctozepto> right
16:54:25 <sean-k-mooney> via host level config options only
16:54:30 <yoctozepto> and defaults to previous default
16:54:37 <bauzas> yeah, so basically a regression wouldn't be a big deal
16:54:47 <sean-k-mooney> we might want to default to unset
16:54:51 <bauzas> changing the options and that's it
16:54:53 <sean-k-mooney> but we could defer that to the implemation
16:54:56 <bauzas> yeah
16:54:59 <sean-k-mooney> to keep it entirly off by defualt
16:55:13 <bauzas> if that's purely additive and host-config based only, doesn't sound a big deal
16:55:23 <yoctozepto> i.e., "do not touch this part of libvirt's xml" by default?
16:55:30 <bauzas> correct
16:55:34 <yoctozepto> makes sense
16:55:34 <bauzas> no upgrade impact
16:55:38 <sean-k-mooney> right we cuurrently dont generate the elements
16:55:44 <sean-k-mooney> so we coudl continue to do that by default
16:55:51 <yoctozepto> agreed
16:55:58 <gibi> I'm OK to grant the exception for this.
16:56:13 <bahnwaerter> sean-k-mooney: Yeah, I could change that. It makes more sense to only set the libvirt entries if they are specified in a nova.conf
16:56:20 <bauzas> yoctozepto: do you have open changes against it ?
16:56:33 <bauzas> oh, that's bahnwaerter's question then
16:56:41 <sean-k-mooney> there is a nova change and nova-specs change open
16:56:50 <yoctozepto> ++
16:56:52 <sean-k-mooney> so if we grant the excption we can update the sepc before we merge it
16:56:54 <bauzas> ok, so there is already a poc
16:57:01 <sean-k-mooney> yes
16:57:10 <bauzas> all the planets are aligned then
16:57:10 <bahnwaerter> bauzas: Yeah, I was invited to this dicussion today ;)
16:57:27 <bauzas> let me take my baton then...
16:58:23 <bauzas> #agreed https://review.opendev.org/c/openstack/nova-specs/+/849488/ granted as a spec deadline exception, sounds reasonable provided there is no upgrade impact and the change being purely self-contained and additive
16:58:38 <bauzas> cores, I'd appreciate if you could review it ASAP
16:58:54 <bauzas> (the spec, tbc)
16:59:18 <bauzas> that's it I guess for today
16:59:20 <sean-k-mooney> ill drop +2 given the pending change to the config behavior
16:59:28 <sean-k-mooney> not quite
16:59:37 <bauzas> sean-k-mooney: about the spec itself
16:59:47 <bauzas> (sean) there seams to be considerable outstanding question with regards to Configurable instance domains
16:59:50 <sean-k-mooney> oh ya so that it for that topic
17:00:07 <sean-k-mooney> yep so just want to make sure we disucssed ^
17:00:09 <bauzas> https://review.opendev.org/c/openstack/nova-specs/+/850048 revert was merged
17:00:23 <bauzas> do we want to grant an exception for it ?
17:00:30 <dansmith> are we on to the domains thing?
17:00:33 <bauzas> yup
17:00:38 <gibi> I do apologize pushing the spec through within such a sort timeframe last week
17:00:39 <bauzas> dns domain this
17:00:48 <dansmith> yeah I still (heartily) question the approach in general
17:00:48 <sean-k-mooney> https://review.opendev.org/c/openstack/nova-specs/+/850352 is the revert of the revert with some issues adressed
17:00:59 <sean-k-mooney> yes
17:01:04 <bauzas> fwiw, we're overtime
17:01:11 <bauzas> so we'll need to end the meeting
17:01:18 <dansmith> I know it will/would be more work to do this via integration with neutron, but it seems like it would be a lot better to do so
17:01:25 <bauzas> but I'd appreciate if people could continue the convo
17:01:38 <sean-k-mooney> bauzas: well we can extned
17:01:43 <sean-k-mooney> its in the nova changel now
17:01:46 <sean-k-mooney> but eitehr way
17:01:49 <bauzas> yeah
17:02:03 <bauzas> this is just we try to stick with one hour
17:02:05 <bauzas> anyway
17:02:14 <sean-k-mooney> dansmith: so do you think we shoudl take a step back and spend more time looking at this
17:02:24 <dansmith> personally I do, yeah
17:02:28 <bauzas> me too
17:02:38 <bauzas> I feel we require a proper brainstorming about it
17:02:39 <sean-k-mooney> then that fine we can defer to AA
17:02:41 <dansmith> I'd like to understand more of what we can and can't do with help from neutron
17:02:44 <sean-k-mooney> and not rush this
17:02:51 <dansmith> codifying this in our API is just a hack, IMHO
17:02:55 <dansmith> sounds good to me
17:03:21 <bauzas> yup, sounds we need a bit of a design time
17:03:25 <sean-k-mooney> im partly worried that we made dission in this space in the past that tie our hand but we may want to revaulate those
17:03:41 <sean-k-mooney> so i think we shoudl spend some time between now and ptg evaulating this again
17:03:47 <sean-k-mooney> including the previous desision
17:03:48 <bauzas> sean-k-mooney: tbh, one week ago, we were still reviewing some metadata API change IIRC
17:04:12 <sean-k-mooney> bauzas: yes which we new would not work for quite a while
17:04:24 <bauzas> which, by reading the superseding spec, I understand why this approach is no longer possible
17:04:43 <sean-k-mooney> we can do the metadta change too
17:04:49 <sean-k-mooney> but it wont help the usecasue
17:04:58 <sean-k-mooney> its just providing more info to the domain
17:05:01 <sean-k-mooney> ... vm
17:05:06 <sean-k-mooney> which it will ignore
17:05:15 <bauzas> but yeah, sounds to me that domains are some information given by the network, not the user
17:05:17 * sean-k-mooney hates i typoed domain instead of vm
17:05:33 <sean-k-mooney> bauzas: i would disagree with that
17:05:40 <sean-k-mooney> but it really depend on the config
17:05:57 <sean-k-mooney> in generally the domain is carried by the port/floating ip and a default domain can be added to the netowrk
17:06:05 <sean-k-mooney> anyway we are over time
17:06:09 <dansmith> I think bauzas meant the network infra,
17:06:13 <dansmith> which is what I meant when I said it
17:06:20 <bauzas> well, unless I'm wrong, DNS is L5
17:06:26 <sean-k-mooney> right
17:06:29 <dansmith> not necessarily "the network object in neutron, distinct from the port object"
17:06:41 <sean-k-mooney> what is greate is this is not integrated with routed network properly either
17:06:48 <bauzas> yeah, not the "neutron network"
17:06:52 <dansmith> and I totally think it does come from network infra, at least in terms of plumbing
17:07:04 <bauzas> I meant 'the network infrastructure"
17:07:06 <sean-k-mooney> dansmith: its ment to be self service
17:07:07 <dansmith> if you override it in your guest OS, that's fine, but we don't need to be involved in that level, IMHO
17:07:17 <sean-k-mooney> at least with designate the model is bring your own domain
17:07:42 <bauzas> this is some data Nova doesn't have to deal with
17:07:43 <dansmith> sean-k-mooney: totally, but we should integrate with the services providing the network infra, even if you took your own domain to them
17:07:47 <sean-k-mooney> you point your domain mx rcords to desigante and then manage it as an enduser independet of the cloud admin
17:07:54 <dansmith> yep, understand
17:08:16 <dansmith> I'm not saying openstack shouldn't handle this, I'm saying I think nova is probably not the right place to set this per-instance
17:08:17 <bauzas> in theory, you could even have your DNS servers totally uncorrelated from OpenStack services
17:08:34 <sean-k-mooney> yes.
17:08:39 <bauzas> but Nova shouldn't be managing it
17:08:52 <sean-k-mooney> anyway im not going to ask for a spec freeze excption for this
17:08:58 <bauzas> this could be some "metadata" information
17:09:10 <bauzas> yeah and we need to end the meeting
17:09:15 <sean-k-mooney> im not sure i agree with "nova shoudl not be managing this" but i understand why you have that view point
17:09:24 <sean-k-mooney> so yes lets end the meeting
17:09:55 <bauzas> let's end the meeting for now
17:09:57 <bauzas> and we'll continue
17:10:00 <bauzas> thanks all
17:10:03 <bauzas> #endmeeting