Re: [Openstack-operators] Question about ancient published OPS and Architecture guides

[Tom Fifield]

On 01/11/16 02:48, Silence Dogood wrote:

you know how many folks are STILL running havana openstack?


Indeed we do - and though the Havana numbers are pretty low now, it is 
entirely true that the vast majority of OpenStack deployments are 
running a release that is already considered "EOL" by upstream :)


Kudos to the docs team for contacting the users about these plans rather 
than taking a blunt line on "EOL", I say.



On Mon, Oct 31, 2016 at 2:44 PM, Andreas Jaeger > wrote:

On 10/31/2016 07:33 PM, Lutz Birkhahn wrote:
> Hi,
>
> I have already manually created PDF versions of about 8 of the
OpenStack Manuals (within about 4-6 hours including setting up the
tool chain and locally fixing some bugs), and working on getting the
rest done (at least those that are in the openstack-manuals.git
repository) within the next few weeks, and make them available to
the public. I’m currently working on an at least 3-phase approach:

Lutz, see

http://specs.openstack.org/openstack/docs-specs/specs/ocata/build-pdf-from-rst-guides.html



Our goal is to publish these PDFs whenever we publish the HTML - so have
always current version.

> phase 1) get as many of the docs in git (openstack-manuals.git )
as possible (mostly manually) converted to PDF and publish an URL
where you can download them.
>
> phase 2) set up a local build pipeline in our own OpenStack cloud
to regularly convert the latest git versions to PDF e.g. every
night, and publish them to the same location, possibly also
providing docs for different versions (e.g. mitaka, neutron, ocata)
>
> phase 3) work with the docs PTL (Lana) or whoever can help with it
to set up the build process on the regular OpenStack / Ubuntu or
whatever build environments so that the build process possibly could
run on the standard build servers, and no longer on our own
machines. Maybe the PDF version will not yet be a gate in the build
process, but it should at least be flagged as a warning when there
are errors, so the right people can look into it and try to fix it
soon, without holding up the rest of the build and release process.

See the referenced specs - and help Ian and others please.

> I was about to contact Lana in Barcelona, and we did meet 2 times,
but we were both too busy with other meetings so didn’t get to talk
about this in Barcelona, but I should be able to track her down on
IRC or email or some other way soon (hopefully, if schedule permits
it ;-) )
>
> I absolutely see a case for PDF files, maybe some time also epub
or mobi, and the tool chain already includes Sphinx as far as I
know, which already provides the ability to create (La)TeX files
which then can easily be typeset into PDF format, probably a few
others as well (unfortunately I also didn’t have time to track down
the Sphinx author, but at least got a lead on that).
>
> HTML is fine for online viewing, but any time you sit in an
airplane (e.g. from or to the Summit) or in a train with bad
Internet connectivity, you’d need to download the whole HTML source
tree, which is much more of a hassle than if you could just download
a PDF or e-book file.
>
> Also even in todays time there are still people who prefer a
printed copy rather than some online doc, e.g. for sitting at the
couch and have the feeling of real paper in your hand, or for taking
it to the beach. I’m thinking about setting up a link somewhere on
the docs site where you can order a printed copy (e.g. some
books-on-demand provider) where you can at any time order a printed
version of the latest doc version. I’ve even ran into to a
“collector” type of person in Barcelona who likes to have all the
books, but usually doesn’t even have time to read them, just the
good feeling of having a lot of beautiful or interesting books…
Sure, this is not everybody’s opinion about book formats, and many
just like the HTML version (which will of course stay nevertheless),
but if there are only 2 to 5 percent of all OpenStack users who’d
like a PDF or printed version, this will still be in the hundreds
I’d guess, maybe thousands
>
> I also urgently request that the existing .Epub and .Mobi versions
are kept at least in some “archives” location, since those are so
far the only examples (that I know of) of carefully edited versions
of the book, even though they are a bit outdated. Not sure if
O’Reilly has some sort of copyright on the looks of the Ops book (we
certainly cannot copy the front page with the "crested agouti”
animal), but in my opinion it can at least be used as an example to
how the future PDF and printed versions of the 

Re: [Openstack-operators] Live-migration CPU doesn't have compatibility

[Chris Friesen]

On 10/27/2016 11:09 PM, William Josefsson wrote:

hi, I did 'virsh capabilities' on the Haswell, which turned out to
list model: Haswell-noTSX. So I set in nova.conf
cpu_model=Haswell-noTSX on both Haswell and Broadwell hosts and it
seems to work. I believe this is my smallest common denominator.


Almost certainly, yes.

Chris

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Question about ancient published OPS and Architecture guides

[Silence Dogood]

you know how many folks are STILL running havana openstack?

On Mon, Oct 31, 2016 at 2:44 PM, Andreas Jaeger  wrote:

> On 10/31/2016 07:33 PM, Lutz Birkhahn wrote:
> > Hi,
> >
> > I have already manually created PDF versions of about 8 of the OpenStack
> Manuals (within about 4-6 hours including setting up the tool chain and
> locally fixing some bugs), and working on getting the rest done (at least
> those that are in the openstack-manuals.git repository) within the next few
> weeks, and make them available to the public. I’m currently working on an
> at least 3-phase approach:
>
> Lutz, see
> http://specs.openstack.org/openstack/docs-specs/specs/
> ocata/build-pdf-from-rst-guides.html
>
> Our goal is to publish these PDFs whenever we publish the HTML - so have
> always current version.
>
> > phase 1) get as many of the docs in git (openstack-manuals.git ) as
> possible (mostly manually) converted to PDF and publish an URL where you
> can download them.
> >
> > phase 2) set up a local build pipeline in our own OpenStack cloud to
> regularly convert the latest git versions to PDF e.g. every night, and
> publish them to the same location, possibly also providing docs for
> different versions (e.g. mitaka, neutron, ocata)
> >
> > phase 3) work with the docs PTL (Lana) or whoever can help with it to
> set up the build process on the regular OpenStack / Ubuntu or whatever
> build environments so that the build process possibly could run on the
> standard build servers, and no longer on our own machines. Maybe the PDF
> version will not yet be a gate in the build process, but it should at least
> be flagged as a warning when there are errors, so the right people can look
> into it and try to fix it soon, without holding up the rest of the build
> and release process.
>
> See the referenced specs - and help Ian and others please.
>
> > I was about to contact Lana in Barcelona, and we did meet 2 times, but
> we were both too busy with other meetings so didn’t get to talk about this
> in Barcelona, but I should be able to track her down on IRC or email or
> some other way soon (hopefully, if schedule permits it ;-) )
> >
> > I absolutely see a case for PDF files, maybe some time also epub or
> mobi, and the tool chain already includes Sphinx as far as I know, which
> already provides the ability to create (La)TeX files which then can easily
> be typeset into PDF format, probably a few others as well (unfortunately I
> also didn’t have time to track down the Sphinx author, but at least got a
> lead on that).
> >
> > HTML is fine for online viewing, but any time you sit in an airplane
> (e.g. from or to the Summit) or in a train with bad Internet connectivity,
> you’d need to download the whole HTML source tree, which is much more of a
> hassle than if you could just download a PDF or e-book file.
> >
> > Also even in todays time there are still people who prefer a printed
> copy rather than some online doc, e.g. for sitting at the couch and have
> the feeling of real paper in your hand, or for taking it to the beach. I’m
> thinking about setting up a link somewhere on the docs site where you can
> order a printed copy (e.g. some books-on-demand provider) where you can at
> any time order a printed version of the latest doc version. I’ve even ran
> into to a “collector” type of person in Barcelona who likes to have all the
> books, but usually doesn’t even have time to read them, just the good
> feeling of having a lot of beautiful or interesting books… Sure, this is
> not everybody’s opinion about book formats, and many just like the HTML
> version (which will of course stay nevertheless), but if there are only 2
> to 5 percent of all OpenStack users who’d like a PDF or printed version,
> this will still be in the hundreds I’d guess, maybe thousands
> >
> > I also urgently request that the existing .Epub and .Mobi versions are
> kept at least in some “archives” location, since those are so far the only
> examples (that I know of) of carefully edited versions of the book, even
> though they are a bit outdated. Not sure if O’Reilly has some sort of
> copyright on the looks of the Ops book (we certainly cannot copy the front
> page with the "crested agouti” animal), but in my opinion it can at least
> be used as an example to how the future PDF and printed versions of the Ops
> book might look like, also including Table of Contents, an Index, and a
> Colophon.
>
>
> Why would a 2 years old epub or mobi be beneficial for you - even in an
> archives location?
>
> Andreas
>
> > I will certainly keep a copy of these 2 files around, and I strongly
> suggest to keep a copy on some publicly available location (if need be, I
> will provide that copy on our servers and make it available to anyone
> interested in them).
> >
> > Just my 2 cents, and no, I’m not yet committing to all of this, just my
> current thoughts (Steve Martinelli, I heard you in the panel… "Do not over
> commit!”)
> >
> > Cheers,
> >
> > 

Re: [Openstack-operators] Question about ancient published OPS and Architecture guides

[Andreas Jaeger]

On 10/31/2016 07:33 PM, Lutz Birkhahn wrote:
> Hi,
> 
> I have already manually created PDF versions of about 8 of the OpenStack 
> Manuals (within about 4-6 hours including setting up the tool chain and 
> locally fixing some bugs), and working on getting the rest done (at least 
> those that are in the openstack-manuals.git repository) within the next few 
> weeks, and make them available to the public. I’m currently working on an at 
> least 3-phase approach:

Lutz, see
http://specs.openstack.org/openstack/docs-specs/specs/ocata/build-pdf-from-rst-guides.html

Our goal is to publish these PDFs whenever we publish the HTML - so have
always current version.

> phase 1) get as many of the docs in git (openstack-manuals.git ) as possible 
> (mostly manually) converted to PDF and publish an URL where you can download 
> them.
> 
> phase 2) set up a local build pipeline in our own OpenStack cloud to 
> regularly convert the latest git versions to PDF e.g. every night, and 
> publish them to the same location, possibly also providing docs for different 
> versions (e.g. mitaka, neutron, ocata)
> 
> phase 3) work with the docs PTL (Lana) or whoever can help with it to set up 
> the build process on the regular OpenStack / Ubuntu or whatever build 
> environments so that the build process possibly could run on the standard 
> build servers, and no longer on our own machines. Maybe the PDF version will 
> not yet be a gate in the build process, but it should at least be flagged as 
> a warning when there are errors, so the right people can look into it and try 
> to fix it soon, without holding up the rest of the build and release process.

See the referenced specs - and help Ian and others please.

> I was about to contact Lana in Barcelona, and we did meet 2 times, but we 
> were both too busy with other meetings so didn’t get to talk about this in 
> Barcelona, but I should be able to track her down on IRC or email or some 
> other way soon (hopefully, if schedule permits it ;-) )
> 
> I absolutely see a case for PDF files, maybe some time also epub or mobi, and 
> the tool chain already includes Sphinx as far as I know, which already 
> provides the ability to create (La)TeX files which then can easily be typeset 
> into PDF format, probably a few others as well (unfortunately I also didn’t 
> have time to track down the Sphinx author, but at least got a lead on that).
> 
> HTML is fine for online viewing, but any time you sit in an airplane (e.g. 
> from or to the Summit) or in a train with bad Internet connectivity, you’d 
> need to download the whole HTML source tree, which is much more of a hassle 
> than if you could just download a PDF or e-book file.
> 
> Also even in todays time there are still people who prefer a printed copy 
> rather than some online doc, e.g. for sitting at the couch and have the 
> feeling of real paper in your hand, or for taking it to the beach. I’m 
> thinking about setting up a link somewhere on the docs site where you can 
> order a printed copy (e.g. some books-on-demand provider) where you can at 
> any time order a printed version of the latest doc version. I’ve even ran 
> into to a “collector” type of person in Barcelona who likes to have all the 
> books, but usually doesn’t even have time to read them, just the good feeling 
> of having a lot of beautiful or interesting books… Sure, this is not 
> everybody’s opinion about book formats, and many just like the HTML version 
> (which will of course stay nevertheless), but if there are only 2 to 5 
> percent of all OpenStack users who’d like a PDF or printed version, this will 
> still be in the hundreds I’d guess, maybe thousands
> 
> I also urgently request that the existing .Epub and .Mobi versions are kept 
> at least in some “archives” location, since those are so far the only 
> examples (that I know of) of carefully edited versions of the book, even 
> though they are a bit outdated. Not sure if O’Reilly has some sort of 
> copyright on the looks of the Ops book (we certainly cannot copy the front 
> page with the "crested agouti” animal), but in my opinion it can at least be 
> used as an example to how the future PDF and printed versions of the Ops book 
> might look like, also including Table of Contents, an Index, and a Colophon.


Why would a 2 years old epub or mobi be beneficial for you - even in an
archives location?

Andreas

> I will certainly keep a copy of these 2 files around, and I strongly suggest 
> to keep a copy on some publicly available location (if need be, I will 
> provide that copy on our servers and make it available to anyone interested 
> in them).
> 
> Just my 2 cents, and no, I’m not yet committing to all of this, just my 
> current thoughts (Steve Martinelli, I heard you in the panel… "Do not over 
> commit!”)
> 
> Cheers,
> 
> /lutz
> 
> 
> 
>> On 31 Oct 2016, at 18:10, Jonathan D. Proulx  wrote:
>>
>>
>> I always use the HTML versions and can't think of a case 

Re: [Openstack-operators] Question about ancient published OPS and Architecture guides

[Lutz Birkhahn]

Hi,

I have already manually created PDF versions of about 8 of the OpenStack 
Manuals (within about 4-6 hours including setting up the tool chain and locally 
fixing some bugs), and working on getting the rest done (at least those that 
are in the openstack-manuals.git repository) within the next few weeks, and 
make them available to the public. I’m currently working on an at least 3-phase 
approach:

phase 1) get as many of the docs in git (openstack-manuals.git ) as possible 
(mostly manually) converted to PDF and publish an URL where you can download 
them.

phase 2) set up a local build pipeline in our own OpenStack cloud to regularly 
convert the latest git versions to PDF e.g. every night, and publish them to 
the same location, possibly also providing docs for different versions (e.g. 
mitaka, neutron, ocata)

phase 3) work with the docs PTL (Lana) or whoever can help with it to set up 
the build process on the regular OpenStack / Ubuntu or whatever build 
environments so that the build process possibly could run on the standard build 
servers, and no longer on our own machines. Maybe the PDF version will not yet 
be a gate in the build process, but it should at least be flagged as a warning 
when there are errors, so the right people can look into it and try to fix it 
soon, without holding up the rest of the build and release process.

I was about to contact Lana in Barcelona, and we did meet 2 times, but we were 
both too busy with other meetings so didn’t get to talk about this in 
Barcelona, but I should be able to track her down on IRC or email or some other 
way soon (hopefully, if schedule permits it ;-) )

I absolutely see a case for PDF files, maybe some time also epub or mobi, and 
the tool chain already includes Sphinx as far as I know, which already provides 
the ability to create (La)TeX files which then can easily be typeset into PDF 
format, probably a few others as well (unfortunately I also didn’t have time to 
track down the Sphinx author, but at least got a lead on that).

HTML is fine for online viewing, but any time you sit in an airplane (e.g. from 
or to the Summit) or in a train with bad Internet connectivity, you’d need to 
download the whole HTML source tree, which is much more of a hassle than if you 
could just download a PDF or e-book file.

Also even in todays time there are still people who prefer a printed copy 
rather than some online doc, e.g. for sitting at the couch and have the feeling 
of real paper in your hand, or for taking it to the beach. I’m thinking about 
setting up a link somewhere on the docs site where you can order a printed copy 
(e.g. some books-on-demand provider) where you can at any time order a printed 
version of the latest doc version. I’ve even ran into to a “collector” type of 
person in Barcelona who likes to have all the books, but usually doesn’t even 
have time to read them, just the good feeling of having a lot of beautiful or 
interesting books… Sure, this is not everybody’s opinion about book formats, 
and many just like the HTML version (which will of course stay nevertheless), 
but if there are only 2 to 5 percent of all OpenStack users who’d like a PDF or 
printed version, this will still be in the hundreds I’d guess, maybe thousands

I also urgently request that the existing .Epub and .Mobi versions are kept at 
least in some “archives” location, since those are so far the only examples 
(that I know of) of carefully edited versions of the book, even though they are 
a bit outdated. Not sure if O’Reilly has some sort of copyright on the looks of 
the Ops book (we certainly cannot copy the front page with the "crested agouti” 
animal), but in my opinion it can at least be used as an example to how the 
future PDF and printed versions of the Ops book might look like, also including 
Table of Contents, an Index, and a Colophon.

I will certainly keep a copy of these 2 files around, and I strongly suggest to 
keep a copy on some publicly available location (if need be, I will provide 
that copy on our servers and make it available to anyone interested in them).

Just my 2 cents, and no, I’m not yet committing to all of this, just my current 
thoughts (Steve Martinelli, I heard you in the panel… "Do not over commit!”)

Cheers,

/lutz



> On 31 Oct 2016, at 18:10, Jonathan D. Proulx  wrote:
> 
> 
> I always use the HTML versions and can't think of a case where I'd
> want the epub or mobi.
> 
> If they are also out dated I definitly think they should be removed
> just to prevent confusion.
> 
> If there's a wider desire for these formats (which I doubt) then
> they'd need to be published much more frequently. I would be
> surprised if there were a need for this and just dropping them is
> likely the best option.
> 
> -Jon
> 
> On Mon, Oct 31, 2016 at 05:51:44PM +0100, Andreas Jaeger wrote:
> :Operators, a quick question from the docs team:
> :
> :We currently publish a frozen epub and mobi version of the 

Re: [Openstack-operators] 2017 Openstack Operators Mid-Cycle Meetups - venue selection etherpads

[Edgar Magana]

Hello,

The PTG is for developers to work on items needed for the release and to get 
together in person to discuss any open topics that they could not resolved 
during the IRC meetings. 
The Forum which is at the same week and place that the OpenStack Conference 
(for instance the next one in Boston) will provide the opportunity to provide 
direct feedback to the developers on the latest release and features for each 
project.

More details here:
https://www.openstack.org/ptg/

This is why we still need to have the Ops mid-cycle Meet-up. This is discussed 
and clarified during the Ops session in BCN.

Now, when I mentioned above “PTG is for developers” I do not want to exclude 
anyone. If you feel like attending the PTG I am pretty sure you will be welcome 
as long as the space is large enough for the ATC members.
BTW. When we compare last time the number of AUCs that are also ATC we found 
that a total of 38% are both. 

Thanks,

Edgar

On 10/27/16, 5:31 AM, "Matthias Runge"  wrote:

On 27/10/16 11:08, Erik McCormick wrote:
> The PTG is for devs to get together and get real work done. We would be
> a distraction from that goal. They will also be attending the forum
> which will run with the summits and will be able to spend more time in
> groups with ops for requirements gathering and such.
> 
> -Erik
> 
> 
> On Oct 27, 2016 11:05 AM, "Jesse Keating"  > wrote:
> 
> I may have missed something, but why aren't we meeting at the
> Project Technical Gathering, which is at the end of February in 
Atlanta?

From my experience with OpenStack, feedback from operators have been
invaluable.

You can easily run things in devstack (or all-in-one deployments), but
this is completely different from running in scale. Operators do tell
you, were the pain-points are. Having a dedicated gathering without
involving actual operators/users is not that useful IMO.

Matthias
-- 
Matthias Runge 

Red Hat GmbH, 
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.de.redhat.com_=DQICAg=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc=G0XRJfDQsuBvqa_wpWyDAUlSpeMV4W1qfWqBfctlWwQ=czgkClZlG5EKd10fcaL9EJL9HH6sy9i1cWQg_-EV5l8=HiIUctBcGN1WC58PVKdrPJ8A_QVJ-Ta9MQgDMFEFqpE=
 , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham,
Michael O'Neill, Eric Shander

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org

https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Doperators=DQICAg=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc=G0XRJfDQsuBvqa_wpWyDAUlSpeMV4W1qfWqBfctlWwQ=czgkClZlG5EKd10fcaL9EJL9HH6sy9i1cWQg_-EV5l8=XYzOkIHTK7m25PpH5i-ibXKmcdfIMG2H0i4wdSaxuA0=
 


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Question about ancient published OPS and Architecture guides

[Jonathan D. Proulx]

I always use the HTML versions and can't think of a case where I'd
want the epub or mobi.

If they are also out dated I definitly think they should be removed
just to prevent confusion.

If there's a wider desire for these formats (which I doubt) then
they'd need to be published much more frequently. I would be
surprised if there were a need for this and just dropping them is
likely the best option.

-Jon

On Mon, Oct 31, 2016 at 05:51:44PM +0100, Andreas Jaeger wrote:
:Operators, a quick question from the docs team:
:
:We currently publish a frozen epub and mobi version of the O'Reilly
:Operations Guide - in the version from 20th May 2014. This is now quite
:different from the HTML version.
:
:The same for the Architecture Design Guide. Our epub is frozen and from
:from 30th October 2014.
:
:We plan to add current PDFs for these documents in the Ocata cycle.
:
:Is there any reason these ancient epub/mobi versions should still get
:published?
:
: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-operators mailing list
:OpenStack-operators@lists.openstack.org
:http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

-- 

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] 2017 Openstack Operators Mid-Cycle Meetups - venue selection etherpads

[Jesse Keating]

This has been my experience as well. I purposefully attend the project fishbowl sessions and often the project mid cycles to be able to provide real time operator feedback as future plans are discussed and retrospectives from the previous release are held.
 
Given a choice between attending either the Ops mid cycle or the PTG, I see far more value in the PTG, which will be held at a very similar time.
-jlk
 
 
- Original message -From: Matthias Runge To: openstack-operators@lists.openstack.orgCc:Subject: Re: [Openstack-operators] 2017 Openstack Operators Mid-Cycle Meetups - venue selection etherpadsDate: Thu, Oct 27, 2016 5:33 AM 
On 27/10/16 11:08, Erik McCormick wrote:> The PTG is for devs to get together and get real work done. We would be> a distraction from that goal. They will also be attending the forum> which will run with the summits and will be able to spend more time in> groups with ops for requirements gathering and such.>> -Erik>>> On Oct 27, 2016 11:05 AM, "Jesse Keating"  > wrote:>>     I may have missed something, but why aren't we meeting at the>     Project Technical Gathering, which is at the end of February in Atlanta?From my experience with OpenStack, feedback from operators have beeninvaluable.You can easily run things in devstack (or all-in-one deployments), butthis is completely different from running in scale. Operators do tellyou, were the pain-points are. Having a dedicated gathering withoutinvolving actual operators/users is not that useful IMO.Matthias--Matthias Runge Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,Commercial register: Amtsgericht Muenchen, HRB 153243,Managing Directors: Charles Cachera, Michael Cunningham,                    Michael O'Neill, Eric Shander___OpenStack-operators mailing listOpenStack-operators@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators 
 


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] Question about ancient published OPS and Architecture guides

[Andreas Jaeger]

Operators, a quick question from the docs team:

We currently publish a frozen epub and mobi version of the O'Reilly
Operations Guide - in the version from 20th May 2014. This is now quite
different from the HTML version.

The same for the Architecture Design Guide. Our epub is frozen and from
from 30th October 2014.

We plan to add current PDFs for these documents in the Ocata cycle.

Is there any reason these ancient epub/mobi versions should still get
published?

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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Neutron Nova Notification and Virtual Interface plugging events

[Kris G. Lindgren]

The reason behind this was that in the past it took neutron a long time to plug 
a vif (especially true on large networks with many boot requests happening at 
the same time)...  Iirc, it was updating the dhcp server that was the slowest 
operation.  Before the nova/neutron notifications nova would start a vm's and 
assume that the vif plug operation was instant.  This would result in a vm's 
booting up potentially without networking.

So now nova will create the vm, pause the vm, wait for neutron to say it's 
finished plugging the vif, then unpause the vm.  Ensuring that all vm's will 
have networking by the time the is boots.

In nova if you set vif plug is fatal and a timeout, the vm's will fail to boot 
if neutron hasn't plugged the vif within the timeout value.  Setting vif plug 
is fatal to false runs with the old behavior in that nova will just boot the 
vm, I do not remember if it waits for the timeout value and continues or if it 
waits at all if is fatal is not set.

Sent from my iPad

> On Oct 31, 2016, at 10:36 AM, Ahmed Mostafa  wrote:
> 
> Hello all, 
> 
> I am a bit confuse by the following parameters :
> 
> notify_nova_on_port_status_change
> notify_nova_on_port_data_change
> 
> The reason i am confused is that i see if there either of these values is set 
> to true (Which is the default), neutron will create a notiva notifier and 
> send these events to nova.
> 
> But i can not understand that part from the nova side, because as i see, when 
> you create a virtual machine you basically call 
> 
> _do_build_and_run_instance, which calls _create_domain_and_network
> 
> These two methods create a virtual machine and a port, then attach that port 
> on the virtual machine
> 
> but in _create_domain_and_network, is see nova waiting for neutron to create 
> the port and it has a neutron_callbak_fail, if neutron should fail in 
> creating the port.
> 
> Now, if i set these values to false, instance creation still will work, so i 
> do not really understand, are these two values critical in creating a virtual 
> machine ? and if not what exactly do they do ?
> 
> Thank you 
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] Neutron Nova Notification and Virtual Interface plugging events

[Ahmed Mostafa]

Hello all,

I am a bit confuse by the following parameters :

notify_nova_on_port_status_change
notify_nova_on_port_data_change

The reason i am confused is that i see if there either of these values is
set to true (Which is the default), neutron will create a notiva notifier
and send these events to nova.

But i can not understand that part from the nova side, because as i see,
when you create a virtual machine you basically call

_do_build_and_run_instance, which calls _create_domain_and_network

These two methods create a virtual machine and a port, then attach that
port on the virtual machine

but in _create_domain_and_network, is see nova waiting for neutron to
create the port and it has a neutron_callbak_fail, if neutron should fail
in creating the port.

Now, if i set these values to false, instance creation still will work, so
i do not really understand, are these two values critical in creating a
virtual machine ? and if not what exactly do they do ?

Thank you
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators