Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-03-01
09:59:37 johnthetubaguy prometheanfire: placement doesn't have a default port, just like keystone, AFAIK
09:59:38 prometheanfire 8780, thanks :D
09:59:55 bauzas prometheanfire: johnthetubaguy: sorry, on meeting atm
09:59:57 johnthetubaguy oh, I guess that kinda is the default
10:00:02 prometheanfire keystone isn't 5000 / 35357 ?
10:00:23 johnthetubaguy well, in theory, none of that matters, you just get the URL from the service catalog
10:00:40 prometheanfire I know it can be discovered, but it's nice to be consistant :P
10:01:06 johnthetubaguy prometheanfire: actually looks like us and keystone might be on 443, technically, https://github.com/openstack-dev/devstack/blob/55dab95237302fa371b88a2edce06de201d83f52/files/apache-keystone.template
10:01:11 johnthetubaguy prometheanfire: but I am not sure
10:01:17 andymccr johnthetubaguy: it's on by default - originally i set it up with a flag but i will probably remove that flag
10:01:38 prometheanfire andymccr: cool, was confused about that :D
10:01:50 johnthetubaguy andymccr: ah, cool, that makes sense, just a transition thing
10:02:01 andymccr prometheanfire: yeah i wanted to set it up prior to it being required and never got it going - and then didn't remove the flag :P
10:02:03 andymccr but yeah it should go now
10:02:21 andymccr either way if you dont force it off - it gets set up
10:02:47 prometheanfire johnthetubaguy: I think it's also on 443 in devstack, but primarily on PUBLICPORT/ADMINPORT
10:03:00 johnthetubaguy yeah, that makes sense
10:05:34 andymccr prometheanfire: there is a discussion about the default ports on the mailing list - essentially there is no default the idea is you use port 80/443 - but we needed one for our backend since we dont have it setup to do that at this point.
10:05:51 andymccr so we went with what the tripleo/puppet people had to keep it at least default in that regard
10:06:16 prometheanfire ya +nova_placement_service_port: 8780
10:18:12 openstackgerrit Béla Vancsics proposed openstack/nova master: Remove unused variable https://review.openstack.org/439516
10:23:26 openstackgerrit Lee Yarwood proposed openstack/nova master: objects: Add attachment_id to BlockDeviceMapping https://review.openstack.org/437665
10:23:27 openstackgerrit Lee Yarwood proposed openstack/nova master: db: Add attachment_id to block_device_mapping https://review.openstack.org/437597
10:23:27 openstackgerrit Lee Yarwood proposed openstack/nova master: Make BlockDeviceMapping object support uuid https://review.openstack.org/242603
10:23:29 openstackgerrit Lee Yarwood proposed openstack/nova master: Add uuid column to BlockDeviceMapping https://review.openstack.org/242602
10:23:29 openstackgerrit Lee Yarwood proposed openstack/nova master: WIP compute: Move detach logic into driver BDM https://review.openstack.org/439520
10:27:30 johnthetubaguy bauzas: do you know the plans around updating install docs for placement? asettle might start chasing you about that :)
10:27:57 johnthetubaguy mriedem_away might be able to co-ordinate the doc update efforts for asettle, as I guess the cells stuff probably needs adding too
10:28:58 prometheanfire johnthetubaguy: yep, that was missing as well
10:30:56 asettle bauzas and mriedem_away - context, the docs here: https://docs.openstack.org/ocata/install-guide-obs/nova.html are out of date and missing some key elements
10:31:11 asettle We'll need to ensure that in future the docs are being updated with each release
10:33:16 johnthetubaguy asettle: I suspect for many thinks will have to wait until the packages are updated after the release, but getting ahead of that can't halm
10:34:14 asettle Yeah, so, in theory you shouldn't have to wait until the packages are updated. Especially if the nova changes in question have nothing ot do with distro packages
10:36:30 bauzas asettle: johnthetubaguy: sorry, was in meeting
10:36:34 bauzas how can I help ?
10:36:51 johnthetubaguy install docs are out of date
10:36:57 johnthetubaguy for placement-api
10:37:04 johnthetubaguy (and cells stuff actually)
10:37:05 asettle bauzas: documentation for the nova portion of the install guide requires updates. ARe there plans to get this updated, or is there someone we can work with to get this updated?
10:41:49 bauzas looks like a huge knowledge transfer to do
10:42:10 bauzas asettle: we have a couple of dev docs that are intended to be user-facing tho
10:44:24 asettle bauzas: if you already have the dev docs, are there any plans to move them and improve on the install guide?
10:47:29 bauzas asettle: well, I did contributed to some docs repo a while ago, but it's a very long story :)
10:47:40 prometheanfire andymccr: still need that mail?
10:47:45 prometheanfire asettle: ^
10:47:48 asettle Hhahaa bauzas I'd be interested to know how it went - if it was bad, we gotta improve, all that et etc
10:47:51 asettle prometheanfire: mail?!
10:47:51 prometheanfire bad tab complete
10:47:55 prometheanfire to the list
10:48:03 bauzas asettle: well, it was 2013, and it went well :)
10:48:21 prometheanfire thought I was in doc channel, been a long day...
10:48:31 asettle prometheanfire: ummm I don't think so :) thank you hahhaha go to bed dude
10:48:46 prometheanfire :D
10:48:48 asettle bauzas: well that's good! Okay, well. Let's get a bit of an action plan together to get these docs updated.
10:48:49 prometheanfire nn
10:49:07 asettle I am probably going to email out to everyone who is a docs liaison to ensure these docs are being updated continuously each release
10:49:12 asettle Seems to be a bit of a problem
10:49:33 johnthetubaguy asettle: we did talk about getting a new person to take that on
10:49:56 johnthetubaguy asettle: the api stuff is all up to date now, we do that when new APIs land
10:50:07 johnthetubaguy well, apart form the concept guide, I mean api-ref
10:50:18 johnthetubaguy asettle: but totally need someone to own the install docs
10:51:03 asettle johnthetubaguy: I would agree. Who is PTL of nova? (pardon my ignorance) we need to reach out and get this organised :)
10:51:35 asettle johnthetubaguy: do we have any OSIC people who would be good for the job? I know they've done that in keystone and glance.
10:51:55 bauzas asettle: FYI, most of the user/deployer notes for placement can be found in https://docs.openstack.org/developer/nova/placement.html
10:52:03 openstackgerrit Moshe Levi proposed openstack/nova master: [WIP] OVS acceleration https://review.openstack.org/398265
10:52:17 asettle bauzas: okay cool :) what's good to know is that it's there, and that we're not creating something out of thin air
10:52:53 openstackgerrit Timofey Durakov proposed openstack/python-novaclient master: Deperecate cell_name cli arg for migration-list https://review.openstack.org/439141
10:52:57 bauzas asettle: for cells v2, deployer instructions are in https://docs.openstack.org/developer/nova/cells.html#setup-of-cells-v2
10:54:08 asettle bauzas: again, good news. A knowledge transfer should be fairly straight forward from here.
10:56:48 johnthetubaguy asettle: lots of that evolved from the OSA feedback too, its just that last (all important) step thats needed really
10:57:02 asettle johnthetubaguy: even better.
10:57:19 asettle Regardless, I think we need to have a better review process at the end of each release.
11:02:18 mdbooth lyarwood johnthetubaguy: multipath
11:02:52 mdbooth Is nova ever going to model multipath as multiple attachments, or only as a single multipath attachment?
11:05:56 johnthetubaguy mdbooth: I was assuming a single attachment, but its a good question
11:06:47 lyarwood mdbooth: I would also say single, why?
11:07:02 sfinucan tonyb: Couldn't find logs/emails about that issue :/ Anywho, we're stuck with Sphinx 1.3.6 you mean?
11:07:38 mdbooth lyarwood: Just trying to think of problems which would be hard to fix
11:07:39 tonyb sfinucan: for a little longer
11:08:10 sfinucan tonyb: Darn.
11:08:14 tonyb sfinucan: http://lists.openstack.org/pipermail/openstack-dev/2017-March/113085.html
11:10:17 sfinucan tonyb: Just for context, why can't we use pbr (and where can't we use it) if it's been capped in some projects
11:10:55 tonyb sfinucan: that's cool it's a little complex
11:12:15 tonyb sfinucan: upper-constraints.txt os a list of every python library need by some part of OpenStack that we knwo works (at least installs) together
11:12:35 tonyb sfinucan: and all nice projects (such as nova) install *only taht version
11:13:12 tonyb sfinucan: sadly when we try to set the version of pbr === 2.0.0 in u-c.txt there are a small number of libraries that can't be installed
11:13:36 tonyb sfinucan: and therefore no part of OpenStack can use that version until they all agree that 2.0.0 is ok
11:14:20 tonyb sfinucan: upper-constraints.txt does a bunch of other things but it's beyond my ability to expalin on IRC late at night (for me)
11:14:57 sfinucan tonyb: ahhh, gotcha
11:15:56 tonyb sfinucan: there are reviews and PRs out to move the ball forward so we'll see how quickly they land and then we can take the next step
11:16:23 sfinucan tonyb: Perfect. Any topic I can look at?
11:16:31 sfinucan Throw a few reviews in
11:16:56 tonyb sfinucan: https://review.openstack.org/#/q/topic:bug/1668848
11:17:38 sfinucan tonyb: fwiw, I'm pretty sure this has been said many times but you can't bump Sphinx until everything is using pbr 2.0, because 1.10 is broken with Sphinx 1.5
11:17:47 sfinucan tonyb: Spot on. Thanks
11:18:45 tonyb sfinucan: right.
11:19:12 sfinucan tonyb: That also would suggest we should be bumping pbr to 2.0, perhaps?
11:19:17 sfinucan or at least blacklisting 1.10
11:20:33 tonyb sfinucan: Yeah we'll set the minimum to 2.0.0 once if tested it a bit
11:21:20 sfinucan tonyb: Cool. Could we blacklist 1.10 also though? Allows us to start using Sphinx 1.5

Earlier   Later