Re: [openstack-dev] [nova][cinder] Nova is now using the Cinder volume attachments API - multiattach comes next

[Jay S. Bryant]

*happy dance*

A huge thanks to Ildiko Vansca (couldn't have made this happen without 
your leadership), Matt Riedemann, John Garbutt and John Griffith for 
making this happen.  You guys have worked so hard on this and it is 
greatly appreciated!


Jay


On 12/9/2017 1:15 PM, Matt Riedemann wrote:
I just wanted to take a minute to recognize that the patch [1] to make 
Nova use the new-style Cinder volume attach flow has merged.


As one can tell from the patch set count alone, this has been in the 
works for a long time now.


We were talking about volume multi-attach support back in Mitaka at 
the midcycle in Bristol. The early talks / patches would have piled 
more technical debt onto Nova and further baked in Nova's need to 
manage volume state, which is something we wanted to avoid, so at the 
Newton summit in Austin we changed course and decided to prioritize 
working on a new data model and API in Cinder, which eventually came 
out as the 3.27 volume attachments API in Ocata.


There was then serious work on both sides in Pike to start using the 
new 3.27 API and we found out we needed some more changes to Cinder, 
which became the 3.44 Cinder API in Queens. Now Nova has merged the 
change at the end of a very long series of changes to enable the new 
flow once 3.44 is available to Nova and computes are all upgraded to 
understand the new flow. One can appreciate the complexity here if you 
read through the Nova spec for the new attach flow [2].


I was really happy to see [1] merge this week because I knew we needed 
to get that in by the queens-2 milestone if we were going to have a 
shot at (1) flushing out stability issues before Queens RC1 and (2) a 
good chance to get multi-attach support into Nova in Queens.


We have a plan for multi-attach support [3] which I think is doable 
before feature freeze. The Cinder 3.48 API is now available too which 
Nova needs to correctly detach a multi-attach volume.


I want to thank everyone that's helped push this along for their 
dedication and patience, especially John Griffith, Ildiko Vancsa, 
Steve Noyes and John Garbutt. And thanks to Sean McGinnis, Jay Bryant, 
Walter Boring and Balazs Gibizer for review support.


We've had weekly meetings between the Nova and Cinder teams for at 
least two years now and I can finally see the end so let's keep up the 
momentum.


[1] https://review.openstack.org/#/c/330285/
[2] 
https://specs.openstack.org/openstack/nova-specs/specs/queens/approved/cinder-new-attach-apis.html
[3] 
https://specs.openstack.org/openstack/nova-specs/specs/queens/approved/cinder-volume-multi-attach.html





__
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

Re: [openstack-dev] [nova][cinder] Nova is now using the Cinder volume attachments API - multiattach comes next

[Melvin Hillsman]

Great work and congratulations to everyone involved!

On Sat, Dec 9, 2017 at 1:15 PM, Matt Riedemann  wrote:

> I just wanted to take a minute to recognize that the patch [1] to make
> Nova use the new-style Cinder volume attach flow has merged.
>
> As one can tell from the patch set count alone, this has been in the works
> for a long time now.
>
> We were talking about volume multi-attach support back in Mitaka at the
> midcycle in Bristol. The early talks / patches would have piled more
> technical debt onto Nova and further baked in Nova's need to manage volume
> state, which is something we wanted to avoid, so at the Newton summit in
> Austin we changed course and decided to prioritize working on a new data
> model and API in Cinder, which eventually came out as the 3.27 volume
> attachments API in Ocata.
>
> There was then serious work on both sides in Pike to start using the new
> 3.27 API and we found out we needed some more changes to Cinder, which
> became the 3.44 Cinder API in Queens. Now Nova has merged the change at the
> end of a very long series of changes to enable the new flow once 3.44 is
> available to Nova and computes are all upgraded to understand the new flow.
> One can appreciate the complexity here if you read through the Nova spec
> for the new attach flow [2].
>
> I was really happy to see [1] merge this week because I knew we needed to
> get that in by the queens-2 milestone if we were going to have a shot at
> (1) flushing out stability issues before Queens RC1 and (2) a good chance
> to get multi-attach support into Nova in Queens.
>
> We have a plan for multi-attach support [3] which I think is doable before
> feature freeze. The Cinder 3.48 API is now available too which Nova needs
> to correctly detach a multi-attach volume.
>
> I want to thank everyone that's helped push this along for their
> dedication and patience, especially John Griffith, Ildiko Vancsa, Steve
> Noyes and John Garbutt. And thanks to Sean McGinnis, Jay Bryant, Walter
> Boring and Balazs Gibizer for review support.
>
> We've had weekly meetings between the Nova and Cinder teams for at least
> two years now and I can finally see the end so let's keep up the momentum.
>
> [1] https://review.openstack.org/#/c/330285/
> [2] https://specs.openstack.org/openstack/nova-specs/specs/queen
> s/approved/cinder-new-attach-apis.html
> [3] https://specs.openstack.org/openstack/nova-specs/specs/queen
> s/approved/cinder-volume-multi-attach.html
>
> --
>
> Thanks,
>
> Matt
>
> __
> 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
>



-- 
Kind regards,

Melvin Hillsman
mrhills...@gmail.com
mobile: (832) 264-2646
__
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

[openstack-dev] [nova][cinder] Nova is now using the Cinder volume attachments API - multiattach comes next

[Matt Riedemann]

I just wanted to take a minute to recognize that the patch [1] to make 
Nova use the new-style Cinder volume attach flow has merged.


As one can tell from the patch set count alone, this has been in the 
works for a long time now.


We were talking about volume multi-attach support back in Mitaka at the 
midcycle in Bristol. The early talks / patches would have piled more 
technical debt onto Nova and further baked in Nova's need to manage 
volume state, which is something we wanted to avoid, so at the Newton 
summit in Austin we changed course and decided to prioritize working on 
a new data model and API in Cinder, which eventually came out as the 
3.27 volume attachments API in Ocata.


There was then serious work on both sides in Pike to start using the new 
3.27 API and we found out we needed some more changes to Cinder, which 
became the 3.44 Cinder API in Queens. Now Nova has merged the change at 
the end of a very long series of changes to enable the new flow once 
3.44 is available to Nova and computes are all upgraded to understand 
the new flow. One can appreciate the complexity here if you read through 
the Nova spec for the new attach flow [2].


I was really happy to see [1] merge this week because I knew we needed 
to get that in by the queens-2 milestone if we were going to have a shot 
at (1) flushing out stability issues before Queens RC1 and (2) a good 
chance to get multi-attach support into Nova in Queens.


We have a plan for multi-attach support [3] which I think is doable 
before feature freeze. The Cinder 3.48 API is now available too which 
Nova needs to correctly detach a multi-attach volume.


I want to thank everyone that's helped push this along for their 
dedication and patience, especially John Griffith, Ildiko Vancsa, Steve 
Noyes and John Garbutt. And thanks to Sean McGinnis, Jay Bryant, Walter 
Boring and Balazs Gibizer for review support.


We've had weekly meetings between the Nova and Cinder teams for at least 
two years now and I can finally see the end so let's keep up the momentum.


[1] https://review.openstack.org/#/c/330285/
[2] 
https://specs.openstack.org/openstack/nova-specs/specs/queens/approved/cinder-new-attach-apis.html
[3] 
https://specs.openstack.org/openstack/nova-specs/specs/queens/approved/cinder-volume-multi-attach.html


--

Thanks,

Matt

__
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

Re: [openstack-dev] [tripleo] [upgrade] CI status and Current effort.

[Wesley Hayutin]

On Fri, Dec 8, 2017 at 10:11 PM, Emilien Macchi  wrote:

> On Fri, Dec 8, 2017 at 11:42 AM, Emilien Macchi 
> wrote:
> > On Fri, Dec 8, 2017 at 5:39 AM, Wesley Hayutin 
> wrote:
> > [...]
> >> Sofer, can you estimate when the redhat-openstack gerrit repo will be
> >> dropped and the upstream
> >> openstac/tripleo-upgrades role used in it's place.  I need to
> coordinate the
> >> CI team to work you and
> >> Jose Louis, however not using the upstream repo makes that difficult.
> >
> > When https://review.openstack.org/#/c/524141/ will be merged - we're
> > working on that. Alex cleanup the repo, today I rebased the patch and
> > added ansble-lint tests. When we have lint working, we'll probably
> > merge the patch.
> > From then, I don't see any blocker to use the upstream repo.
>
> OK, https://review.openstack.org/#/c/524141/ is now ready for review.
> I had to rebase
> https://review.openstack.org/#/c/524141/2..4/templates/
> create_registry_env.sh.j2
> - please carefully review this one.
>
> Otherwise, we fixed lint and update the CI job, all looks good.
> Once we land it, we need to make sure we have all commits from the old
> repo, and then we need to kill the repo (following this commit:
> https://github.com/openstack/puppet-tuskar/commit/
> d54150a1ad61034cb73c6160fb57956d30f2b2d9).
> Then, use the new repo, and enjoy.
>

We also need to be sure to setup CI properly on the
openstack/tripleo-upgrade repo :)


>
> Thanks,
> --
> Emilien Macchi
>
> __
> 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
>
__
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

Re: [openstack-dev] [Release-job-failures][congress] Pre-release of openstack/congress failed

[Doug Hellmann]

Excerpts from Eric K's message of 2017-12-09 03:03:10 -0800:
> Submitted this after merging the fix:
> https://review.openstack.org/#/c/526834/
> 
> Is that the correct step? Thanks again!

The 0b2 tag was applied successfully, and our tools don't make it easy
to move the tag after the fact (there are reasons that's not a good idea
anyway). So we should either tag a new version (0b3) or just leave it
alone and count this as a successful use of milestones to detect
packaging/release issues.

Doug

> 
> On 12/8/17, 2:10 PM, "Sean McGinnis"  wrote:
> 
> >On Fri, Dec 08, 2017 at 04:06:15PM -0600, Doug Hellmann wrote:
> >> Excerpts from zuul's message of 2017-12-08 21:56:33 +:
> >> > Build failed.
> >> > 
> >> > - release-openstack-python-without-pypi
> >>http://logs.openstack.org/08/080df7f0b147dc8290cc9ceb513ba5d8c1f8f295/pre
> >>-release/release-openstack-python-without-pypi/8c423e5/ : FAILURE in 5m
> >>53s
> >> > - announce-release announce-release : SKIPPED
> >> > 
> >> 
> >> This error looks like there is a bad file reference in the MANIFEST.in:
> >> 
> >> error: can't copy 'etc/policy.json': doesn't exist or not a regular file
> >> ERROR: InvocationError:
> >> 
> >>'/home/zuul/src/git.openstack.org/openstack/congress/.tox/venv/bin/python
> >> setup.py bdist_wheel'
> >> venv finish: runtests after 2.76 seconds
> >
> >I think this is needed to fix it. Some missing cleanup work from the
> >policy-in-code activity.
> >
> >https://review.openstack.org/#/c/526274/
> >
> >
> >__
> >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
> 

__
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

Re: [openstack-dev] [keystone] keystone client service_catalog is None

[Boris Bobrov]

Hi,

Have a look at how openstackclient does this. Read this code:
https://github.com/openstack/python-openstackclient/blob/master/openstackclient/identity/v3/catalog.py#L43
and then this code:
https://github.com/openstack/osc-lib/blob/master/osc_lib/clientmanager.py#L239


On 09.12.2017 04:15, Eric K wrote:
> Hi all,
> 
> I'm working on some code [1] that attempts to retrieve a endpoint from the
> service_catalog, but the service_catalog comes up None. Any suggestions on
> what I need to do differently to get a working service_catalog? Thanks
> very much!
> 
> Python 2.7.12 (default, Nov 20 2017, 18:23:56)
> [GCC 5.4.0 20160609] on linux2
 from keystoneauth1 import session # Version 2.12.1
 from keystoneauth1.identity import v2
 import keystoneclient.v3.client as ksclient
 auth = v2.Password(auth_url='http://127.0.0.1/identity',
 username='admin', password='password', tenant_name='admin')
 sess = session.Session(auth=auth)
 keystone = ksclient.Client(session=sess)
 print(keystone.service_catalog)
> None
> 
> 
> 
> [1] 
> https://review.openstack.org/#/c/526813/1/congress/datasources/monasca_driv
> er.py@94
> 
> 
> 
> __
> 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
> 

__
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

[openstack-dev] [evoque] Retiring evoque projects

[Andreas Jaeger]

Evoque cores,

The last change merged to the evoque projects was January 2016, I 
propose to retire the projects to avoid people commiting to them and 
infra updating their jobs needlessly.


See
https://docs.openstack.org/infra/manual/drivers.html#retiring-a-project 
on how to retire them.


If you need help retiring, please tell me,

Andreas
--
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
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

[openstack-dev] [cerberus] Retire openstack/*cerberus*

[Andreas Jaeger]

Anthony, Christophe, Gauvin,

The last merge to one of the cerberus repositories was December 2015, I 
propose to retire the repositories to avoid people submitting changes to 
them.


See 
https://docs.openstack.org/infra/manual/drivers.html#retiring-a-project 
on how to retire a project.


If you need help with retiring, please tell me,

Andreas
--
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
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

[openstack-dev] [astara] Retire openstack/*astara*

[Andreas Jaeger]

Ryan, Mark,

nothing has merged to the OpenStack astara repos since over a year (last 
merge was October 2016).


I suggest to retire the repos completely as explained at 
https://docs.openstack.org/infra/manual/drivers.html#retiring-a-project 
to avoid people to submit patches to it.


Could you do the steps, please?

I'm happy to help you with it, if you prefer,

Andreas
--
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
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

[openstack-dev] [all][infra] Playbooks need extension, otherwise job will fail

[Andreas Jaeger]

Playbooks in Zuul v3 config files now need the file extension like 
".yaml". There are still a few ancient changes for zuul.yaml that do not 
have those - and some repos that did not take in Jim's update.


If your jobs are failing with errors that playbooks cannot be found, add 
the file extension - or merge the open change. See the list of open 
changes on what needs to be done.


Open changes:
https://review.openstack.org/#/q/topic:zuulv3-paths+status:open

Andreas
--
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
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

Re: [openstack-dev] [all] Changes to releasenotes and docs build jobs

[Andreas Jaeger]

On 11/22/2017 07:39 AM, Monty Taylor wrote:

Hey everybody!

Following recent changes [0] in the PTI [1][2] we're rolling out some 
changes to the build-openstack-releasenotes and 
build-openstack-sphinx-docs jobs. If you see patches with the topic 
'updated-pti' - they are in service of this.


The most important thing to be aware of is that we'll no longer be using 
tox for either of them. There are a few reasons for that - the one 
that's most important to me is that it allows us to use the exact same 
docs and releasenotes build jobs for python, go, javascript or any other 
language without needing to add python build tooling to non-python 
repos. We'll also align more with how readthedocs does things in the 
broader python ecosystem.


It's also worth reminding people that we've NEVER used 'tox -edocs' in 
the gate for docs jobs - so anyone who has additional things in their 
docs environment has not been having those things run. For folks running 
doc8, we recommend adding those checks to your pep8 environment instead.


It's also worth noting that we're adding support for a 
doc/requirements.txt file (location chosen for alignment readthedocs) to 
express requirements needed for all docs (for both releasenotes and 
docs). We'll start off falling back to test-requirements.txt ... but, we 
recommend splitting doc related requirements into doc/requirements.txt - 
since that will mean not needing to install Sphinx when doing tox 
unittests.


Specific info
=

Releasenotes


The patches for releasenotes have been approved and merged.

* We use -W for all releasenotes builds - this means warnings are always 
errors for releasenotes. That shouldn't bother anyone, as most of the 
releasenotes content is generated by reno anyway.


* We're temporarily installing the project to get version number. Doing 
this will be removed as soon as the changes in 
topic:releasenotes-version land. Note this only changes the version 
number on the front page, not what is shown. topics:releasenotes-version


The majority of the changes for this have merged, let's move forward:

https://review.openstack.org/526850




* Installs dependencies via bindep for doc environment.

* doc/requirements.txt is used for installation of python dependencies. 
Things like whereto or openstackdocstheme should go there.


Documentation builds


* We use -W only if setup.cfg sets it

* Installs dependencies via bindep for doc environment. Binary deps, 
such as graphviz, should be listed in bindep and marked with a 'doc' tag.


* doc/requirements.txt is used for installation of python dependencies.
Things like whereto or openstackdocstheme should go there.

* tox_install.sh used to install project if it exists. Because of the 
current situation with neutron and horizon plugins it's necessary to run 
tox_install.sh if it exists as part of setup. We eventually want to make 
that go away, but that's a different effort. There are seven repos with 
a problematic tox_install.sh - patches will be arriving to fix them, and 
we won't land the build-openstack-sphinx-docs changes until they have 
all landed.


For many projects, tox_install.sh is not needed at all and can be easily 
replaced. Changes are up for those that we can replace easily - and many 
are already merged. For open changes, see


https://review.openstack.org/#/q/status:open++topic:rm-tox_install

Please review and merge,

Andreas




We've prepared these with a bunch of depends-on patches across a 
collection of projects, so we don't anticipate much in the way of pain 
... but life happens, so if you notice anything go south with 
releasenotes or sphinx jobs, please let us know and we can help solve 
any issues.


Thanks!
Monty

[0] https://review.openstack.org/#/c/509868
[1] https://review.openstack.org/#/c/508694
[2] 
https://governance.openstack.org/tc/reference/project-testing-interface.html 



__
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



--
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
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

[openstack-dev] Introduction

[courage angeh]

Hi guys,

My name is Angeh Courage, computer engineering student at the University of
Buea currently in my forth year of studies. Was a GSoC intern at Mifos
Initiavie for 2016/2017 and I am good with Python, Java - Spring, web(HTML,
CSS, JS - React, Angular...)
I am very interested in cloud computing and containerization and also
interested contributing to openstack and I will like some help on where I
should get started.

Thanks,
Angeh
__
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

Re: [openstack-dev] [Release-job-failures][congress] Pre-release of openstack/congress failed

[Eric K]

Submitted this after merging the fix:
https://review.openstack.org/#/c/526834/

Is that the correct step? Thanks again!

On 12/8/17, 2:10 PM, "Sean McGinnis"  wrote:

>On Fri, Dec 08, 2017 at 04:06:15PM -0600, Doug Hellmann wrote:
>> Excerpts from zuul's message of 2017-12-08 21:56:33 +:
>> > Build failed.
>> > 
>> > - release-openstack-python-without-pypi
>>http://logs.openstack.org/08/080df7f0b147dc8290cc9ceb513ba5d8c1f8f295/pre
>>-release/release-openstack-python-without-pypi/8c423e5/ : FAILURE in 5m
>>53s
>> > - announce-release announce-release : SKIPPED
>> > 
>> 
>> This error looks like there is a bad file reference in the MANIFEST.in:
>> 
>> error: can't copy 'etc/policy.json': doesn't exist or not a regular file
>> ERROR: InvocationError:
>> 
>>'/home/zuul/src/git.openstack.org/openstack/congress/.tox/venv/bin/python
>> setup.py bdist_wheel'
>> venv finish: runtests after 2.76 seconds
>
>I think this is needed to fix it. Some missing cleanup work from the
>policy-in-code activity.
>
>https://review.openstack.org/#/c/526274/
>
>
>__
>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



__
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

Re: [openstack-dev] [horizon][heat] heat-dashboard is ready for Horizon team's review

[Kaz Shinohara]

Hi all,


I've confirmed a couple of things below.

- heat-dashboard is released in queens-2  Thx! Rico :)
  you can see the release tag 1.0.0 in
http://git.openstack.org/cgit/openstack/heat-dashboard/

- Dropped heat related code from horizon repo. Thx! Akihiro :)
  
http://git.openstack.org/cgit/openstack/horizon/commit/?id=b4fccffccca501388b0e1800375f3e6c7efaea81

Looks head-dashboard successfully takes over from horizon.
#opened bugs too ;) https://bugs.launchpad.net/heat-dashboard

Thank you very much for your cooperation so far.
And if I missed something to do, please kindly give me a shout.

Regards,
Kaz Shinohara


2017-12-06 23:30 GMT+09:00 Kaz Shinohara :
> Hi Akihiro, Horizon team,
>
>
> Thanks a lot for your help as always:)
>
>>> Thanks for updating the horizon patch. Is it ready to merge from the
>>> perspective of heat dashboard team?
> Yes, we think it's ready to be merged.
>
>>> Perhaps the system panel needs to be pluggable.
>>> As of now, it sounds no problem to remove the list of head services 
>>> temporarily.
> I had talked with Heat team & got no objection on this, looks it's ok
> to remove it temporarily.
> Making it pluggable sounds nice, hopefully we will have further
> discussion in next PTG.
>
>> IIRC about 25 bugs were forwarded. I hope heat-dashboard team can
>> investigate them.
> Thank you, we will work for them!
>
> Regards,
> Kaz
>
>
>
> 2017-12-06 15:49 GMT+09:00 Akihiro Motoki :
>> I have another announcement on heat-dashboard split out.
>>
>> I moved the horizon bugs related to heat to heat-dashboard launchpad
>> project last week.
>> IIRC about 25 bugs were forwarded. I hope heat-dashboard team can
>> investigate them.
>>
>> Akihiro
>>
>> 2017-12-06 15:46 GMT+09:00 Akihiro Motoki :
>>> Hi Kaz,
>>>
>>> 2017-12-05 18:45 GMT+09:00 Kaz Shinohara :
 Hi Akihiro, Horizon & Heat team,


 We've slightly updated your change for the split out, please check
 https://review.openstack.org/#/c/523402/
>>>
>>> Thanks for updating the horizon patch. Is it ready to merge from the
>>> perspective of heat dashboard team?
>>>
 One non-voting job failed but hopefully not related to this change.
>>>
>>> The failing non-voting job is not related to the patch.
>>> It is for Django 2.0 support but horizon has not support Django 2.0,
>>> so it always fails now.
>>>
 In parallel, we could confirm that heat-dashboard works without any
 issue along with this change.

 Also resolved the points what Akihiro kindly commented.
 https://etherpad.openstack.org/p/heat-dashboard-review-point

 The thing we should discuss going forward is how to handle admin info
 panel for Heat.
 Personally information we can see from the panel is really limited,
 just a list of heat engine services, so might be ok to be removed.
 https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/admin/info/tables.py#L256
 I've never seen other dashboards supporting admin functions, better to
 follow others & keep simplicity.
 Any opinion will be welcome :)
>>>
>>> Yeah, it makes sense.
>>>
>>> Perhaps the system panel needs to be pluggable.
>>> As of now, it sounds no problem to remove the list of head services 
>>> temporarily.
>>>
>>> Thanks,
>>> Akihiro
>>>

 Regards,
 Kaz


 2017-11-29 12:39 GMT+09:00 Kaz Shinohara :
> Hi Akihiro,
>
>
> Thanks for your quick response!
>
> As you requested, we will check & update your patch to slit out heat
> support from Horizon repo.
> https://review.openstack.org/#/c/523402/
>
> Also replied for your comment in our etherpad, please kindly check.
> https://etherpad.openstack.org/p/heat-dashboard-review-point
>
> Regards,
> Kaz
>
> 2017-11-28 21:08 GMT+09:00 Akihiro Motoki :
>> Hi Kaz,
>>
>> Good hear the good progress of heat-dashboard. Thanks.
>>
>> I created a blueprint in horizon to track the effort (mainly in
>> horizon side) and assign it to you:
>> https://blueprints.launchpad.net/horizon/+spec/heat-dashboard-split-out
>> I also left comments in your etherpad.
>>
>> I think it is time to prepare a patch which drops heat-dashboard code
>> from horizon and test the new dashboard with it. Could you propose the
>> patch?
>>
>> Thanks,
>> Akihiro
>>
>>
>> 2017-11-28 16:32 GMT+09:00 Kaz Shinohara :
>>> Hi Horizon team,
>>>
>>>
>>> As I talked with Rob & Ying in Sydney, now heat-dashboard repo is
>>> ready, please kindly review it.
>>>
>>> http://git.openstack.org/cgit/openstack/heat-dashboard
>>>
>>> Also we described points to be clarified in this review, if you find
>>> anything to be noted/fixed, please feel free to put your comment on
>>> this 

Re: [openstack-dev] [E] [openstack-ansible] Cannot connect to proxy server from infra1-repo-container

[Jean-Philippe Evrard]

On 7 December 2017 at 14:02, Gordon, Kent S
 wrote:
> On Thu, Dec 7, 2017 at 3:24 AM, Goutham Pratapa
>  wrote:
>> Hi,
>>
>> We are trying test environment deployment with OpenStack-ansible pike
>> release. After executing setup-hosts.yaml, the lxc-containers were created.
>> We have an issue while doing
>> apt-get update in infra-repo-container as it couldn't connect to the proxy
>> server.
>> The strange thing is that the infra-repo-container is not showing ip on any
>> interface when checked with ip r.
>>
>> Could you please help us with this issue. Below are some logs on the
>> container and on the host.
>>
>> E: Failed to fetch
>> http://security.ubuntu.com/ubuntu/dists/xenial-security/main/binary-amd64/Packages
>> Something wicked happened resolving 'xx.xx.xx.xx:8080' (-9 - Address family
>> for hostname not supported)
>>
>> root@infra1-repo-container-a7a137c4:/# ping xx.xx.xx.xx (proxy server)
>> connect: Network is unreachable
>>
>> On Container:
>>
>> root@infra1-repo-container-a7a137c4:/# cat /etc/network/interfaces
>> # The loopback network interface
>> auto lo
>> iface lo inet loopback
>> # LXC interface, this is ALWAYS assumed to be DHCP.
>> auto eth0
>> iface eth0 inet dhcp
>> # Load any additional configs
>> source /etc/network/interfaces.d/*.cfg
>>
>> root@infra1-repo-container-a7a137c4:/# cat
>> /etc/network/interfaces.d/eth1.cfg
>> # Ansible managed
>>
>> ### start generated network for [ eth1 ] ###
>> auto eth1
>> iface eth1 inet static
>> address 192.168.124.126
>> netmask 255.255.255.0
>> mtu 1500
>> post-up sysctl -w net.ipv4.conf.$IFACE.arp_notify=1
>> post-up ip link set $IFACE address $(cat /sys/class/net/$IFACE/address)
>> ### end generated network for [ eth1 ] ###
>> root@infra1-repo-container-a7a137c4:/# route -n
>> Kernel IP routing table
>> Destination Gateway Genmask Flags Metric RefUse
>> Iface
>>
>> On host:
>>
>> root@ubuntu:/home/ansible# ifconfig lxcbr0
>> lxcbr0Link encap:Ethernet  HWaddr fe:02:f2:ff:bd:86
>>   inet addr:10.0.3.1  Bcast:10.0.3.255  Mask:255.255.255.0
>>   inet6 addr: fe80::a085:76ff:febb:401d/64 Scope:Link
>>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>>   RX packets:691 errors:0 dropped:0 overruns:0 frame:0
>>   TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
>>   collisions:0 txqueuelen:1000
>>   RX bytes:181224 (181.2 KB)  TX bytes:828 (828.0 B)
>> root@ubuntu:/home/ansible# ip r
>> default via 192.168.124.1 dev eno1
>> 10.0.3.0/24 dev lxcbr0  proto kernel  scope link  src 10.0.3.1
>> 192.168.124.0/24 dev eno1  proto kernel  scope link  src 192.168.124.28
>> 192.168.124.0/24 dev br-mgmt  proto kernel  scope link  src 192.168.124.28
>>
>>
>> Thanks in advance...
>>
>> --
>> Thanks !!!
>> Goutham Pratapa
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev=DwIGaQ=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=Xkn6r0Olgrmyl97VKakpX0o-JiB_old4u22bFbcLdRo=WEmA5tlLT-4nxWR8GoeTS7dM7n6BX52-5ELlKu5-o4c=RjnZBhACZLdykt8ETppf88EEKeePLRoCWZYV060iJw8=
>>
>
> Is a AIO or multi host setup?
>
> I have found places in openstack ansible that bypass the proxy server 
> variables.
> My memory was is that it was using systemd to fetch files in certain
> cases and that systemd did not honor proxy variables.
> I have ended up using a secondary proxy on the deployment host along
> with a NAT setup
> on the deployment host that made sure to send external requests to the proxy.
>
>
>
> --
> Kent S. Gordon
> kent.gor...@verizonwireless.com Work:682-831-3601 Mobile: 817-905-6518
>
> __
> 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

Could you show your bridges on the host too? And your openstack_user_config.yml?
When the repo-server gets installed, it installs a reverse proxy. All
the nodes are then configured to use the repo server(s).
So all the nodes need to reach it, on the management network.

Here you are a little early in the steps, you can't install the repo
server because you don't have connectivity in your containers. That
shouldn't happen. You have maybe a misconfiguration, or something
happened to your containers that ended up with no IP assigned on the
containers.
Maybe try to restart your repo container, see if it works better. Else
I'd advise to debug this problem a little more in depth.

You could join us on our irc channel #openstack-ansible for help.

Best regards,