Re: [openstack-dev] [release][Congress] Congress Newton RC2 available (Congress Newton RC1 available)
Please verify RC2: https://tarballs.openstack.org/congress/congress-4.0.0.0rc2.tar.gz Thanks, Dims On Fri, Sep 16, 2016 at 12:45 PM, Davanum Srinivas wrote: > Hello everyone, > > The release candidate for Congress for the end of the Newton cycle > is available! You can find the RC1 source code tarball at: > > https://tarballs.openstack.org/congress/congress-4.0.0.0rc1.tar.gz > > Unless release-critical issues are found that warrant a release > candidate respin, this RC1 will be formally released as the final > Newton release on 6 October. You are therefore strongly > encouraged to test and validate this tarball! > > Alternatively, you can directly test the stable/newton release > branch at: > > http://git.openstack.org/cgit/openstack/congress/log/?h=stable/newton > > If you find an issue that could be considered release-critical, > please file it at: > > https://bugs.launchpad.net/congress/+filebug > > and tag it *newton-rc-potential* to bring it to the Congress release > crew's attention. > > Note that the "master" branch of Congress is now open for Ocata > development, and feature freeze restrictions no longer apply there! > > Thanks, > Dims (On behalf of the Release Team) > > -- > Davanum Srinivas :: https://twitter.com/dims -- Davanum Srinivas :: https://twitter.com/dims __ 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][i18n] do we need translation mark for strings in tests?
On 10/1/2016 5:49 PM, Matt Riedemann wrote: No you shouldn't need to mark strings for translation in test code. I believe we have a hacking rule for marking LOG.info/warning/error messages for translation but it should skip test directories. Ah I guess the hacking rule is nova-specific: https://github.com/openstack/nova/blob/2851ceaed3010c19f42e308be637b952edab092a/nova/hacking/checks.py#L342 -- Thanks, Matt Riedemann __ 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][i18n] do we need translation mark for strings in tests?
On 10/1/2016 9:48 AM, Akihiro Motoki wrote: Hi, I noticed strings in tests (unit tests or others) have translation marks (_, _LE and so on). Do we need translation marks for them? I don't think so for most cases from various reasons below. Only exception is to test translations. From translators: - Effort to translate strings in tests leads is meaningless. Such translations are never used. - Strings from test code drop the translation percentage. The current translation import script checks the translation percentage and imports translations with >75% percentage. From developers: - Translation mark is actually unnecessary but developers are requested to mark them as translatable. It is annoying. Thought? Thanks, Akihiro __ 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 No you shouldn't need to mark strings for translation in test code. I believe we have a hacking rule for marking LOG.info/warning/error messages for translation but it should skip test directories. -- Thanks, Matt Riedemann __ 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][i18n] do we need translation mark for strings in tests?
Akihiro Motoki wrote: Hi, I noticed strings in tests (unit tests or others) have translation marks (_, _LE and so on). Do we need translation marks for them? I don't think so for most cases from various reasons below. Only exception is to test translations. From translators: - Effort to translate strings in tests leads is meaningless. Such translations are never used. - Strings from test code drop the translation percentage. The current translation import script checks the translation percentage and imports translations with >75% percentage. From developers: - Translation mark is actually unnecessary but developers are requested to mark them as translatable. It is annoying. Thought? Thanks, Akihiro I believe we should not only not use marks in tests, but forbid them with a hacking check. It’s a waste of translator time. Ihar __ 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] [elections] TC candidacy
OpenStack ensures people have a choice. We give developers choices, which gives deployers choices, which ensures consumers have choices. We make choices, evaluate results, revisit and choose again. OpenStack creates space; personal space, public space. The choice is available. By virtue of OpenStack's existence people retain belief in themselves. They retain belief in what they can create with others. OpenStack is an international experience. Not only is there an opportunity to listen and understand people with different perspectives and life experiences, it is a daily occurrence. In no other environment have I spent so much time considering what the weather is in China, if France is on holiday at the moment, whether my co-workers are safe. I spend time thinking about the people I work with more than in any other prior environment. Your lives are all so very different from my own. Yet for the most part, I believe we want similar things, to be useful, to help others and to create something together that is also useful and helps others. Thank you for reading. Please vote, Anita. __ 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] TC Candidacy - amrith
I would like to announce my candidacy for election to the OpenStack Technical Committee. By way of introduction, I[1] have been working primarily on Trove since just before Icehouse. I was the PTL of the project for the Newton cycle, and was recently elected to a second term as the PTL for the Ocata cycle. I am also active in the Stewardship Working Group (SWG)[2]. I believe that a place on the TC is an opportunity to serve the OpenStack community. An important aspect of leadership is something called 'servant leadership', the notion that leaders are there to serve the rest of their constituents. This is also a concept central to the SWG which I am a part of. If elected to the TC, it would be my privilege to serve all of you. What does that mean? The charter of the OpenStack Technical Committee[3] charges the TC with providing 'technical leadership'. There are however a number of questions that must be answered such as "What is OpenStack", and I submit to you that these are not necessarily just 'technical'. The TC has been spending a lot of time trying to answer some of these. Some of this makes total sense, but then there are are questions about what 'maturity' is, and who an 'active reviewer' is. The TC has been spending an inordinate of time trying to decide what metrics or attributes of a contributor it can measure, and then proceeding to define activity and maturity in terms of those things. I submit to you that these latter things are a huge distraction. In the process, I believe that there are significant 'technical' issues that have paid the penalty, for example the notion of cross project goals (series goals [4]), one that I strongly believe are meaningful and within the scope of the TC. If elected to the TC, I would like to use my position to urge the TC to spend more time on the important things like "How do we make OpenStack better for users", and "How can we make a cross-project goal for python3 work", and less of its time on the distractions that have been numerous of late. In a nutshell, I'd like to put more of the "technical" back into the "Technical Committee", and re-focus it on serving the OpenStack community, the very essence of Stewardship. Thank you for your reading, and I appreciate your support, and giving me the opportunity to SERVE YOU on the Technical Committee. -amrith [1] http://www.openstack.org/community/members/profile/15733 [2] https://governance.openstack.org/resolutions/20160705-stewardship.html [3] https://governance.openstack.org/reference/charter.html [4] https://review.openstack.org/#/c/349068/ __ 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][i18n] do we need translation mark for strings in tests?
Hi, I noticed strings in tests (unit tests or others) have translation marks (_, _LE and so on). Do we need translation marks for them? I don't think so for most cases from various reasons below. Only exception is to test translations. >From translators: - Effort to translate strings in tests leads is meaningless. Such translations are never used. - Strings from test code drop the translation percentage. The current translation import script checks the translation percentage and imports translations with >75% percentage. >From developers: - Translation mark is actually unnecessary but developers are requested to mark them as translatable. It is annoying. Thought? Thanks, Akihiro __ 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] [tricircle]
Glad to see you here sir :) Best Regards, Swapnil On Fri, Sep 30, 2016 at 6:17 PM, Chandrakant Bagade wrote: > Hello , > > > > Myself Chandrakant Bagade , working at Persistent System Ltd. > > I was trying Tricircle with devstack and found it , a very helpful idea to > datacenter management. > > > > I can see feature like provisioning , image/vm/volume management therein. > > I was wondering if features like monitoring/inventory management is also > available there or planned for coming released. I read the docs but couldn’t > find the information. > > > > Can someone from Tricircle team , help me with my query. If these are > available , then pointer/documents to those would be much appreciated. > > > > Thanks, > > Chandrakant > > DISCLAIMER == This e-mail may contain privileged and confidential > information which is the property of Persistent Systems Ltd. It is intended > only for the use of the individual or entity to which it is addressed. If > you are not the intended recipient, you are not authorized to read, retain, > copy, print, distribute or use this message. If you have received this > communication in error, please notify the sender and delete all copies of > this message. Persistent Systems Ltd. does not accept any liability for > virus infected mails. > > > __ > 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] [cinder][db] lazy loading of an attribute impossible
On 09/30/2016 10:54 AM, Roman Podoliaka wrote:
Michał,
You are absolutely right: this exception is raised when you try to
lazy-load instance attributes outside a Session scope. There is an
obvious problem with that - instances do not communicate with a DB on
their own - it's left up to Session [1].
Unfortunately, it does not play nicely with the "classic" DB access
layer we have in Cinder and other projects, when you have a notion of
pluggable DB APIs and SQLAlchemy implementation that looks like:
@require_context
@handle_db_data_error
def snapshot_create(context, values):
values['snapshot_metadata'] = _metadata_refs(values.get('metadata'),
models.SnapshotMetadata)
if not values.get('id'):
values['id'] = str(uuid.uuid4())
session = get_session()
with session.begin():
snapshot_ref = models.Snapshot()
snapshot_ref.update(values)
session.add(snapshot_ref)
return _snapshot_get(context, values['id'], session=session)
In this case a Session (and transaction) scope is bound to "public" DB
API functions. There are a few problems with this:
1) once a public DB function returns an instance, it becomes prone to
lazy-load errors, as the corresponding session (and DB transaction) is
already gone and it's not possible to load missing data (without
establishing a new session/transaction)
2) you have to carefully pass a Session object when doing calls to
"private" DB API functions to ensure they all participate in the very
same DB transaction. Otherwise snapshot_get() above would not see the
row created by snapshot_create() due to isolation of transactions in
RDBMS
3) if you do multiple calls to "public" DB API functions when handling
a single HTTP request it's not longer easy to do a rollback as every
function creates its own DB transaction
Mixing of Session objects creation with the actual business logic is
considered to be an anti-pattern in SQLAlchemy [2] due to problems
mentioned above.
At this point I suggest you take a look at [3] and start using in
Cinder: in Kilo we did a complete redesign of EngineFacade in oslo.db
- it won't solve all you problems with lazy-loading automatically, but
what it can do is provide a tool for declarative definition of session
(and transaction) scope, so that it's not longer limited to one
"public" DB API function and you can extend it when needed: you no
longer create a Session object explicitly, but rather mark methods
with a decorator, that will inject a session into the context, and all
callees will participate in the established session (thus, DB
transaction) rather than create a new one (my personal opinion is that
for web-services it's preferable to bind session/transaction scope to
the scope of one HTTP request, so that it's easy to roll back changes
on errors - we are not there yet, but some projects like Nova are
already moving the session scope up the stack, e.g. to objects layer).
+1 thanks Roman !
Thanks,
Roman
[1]
http://docs.sqlalchemy.org/en/latest/orm/session_basics.html#what-does-the-session-do
[2]
http://docs.sqlalchemy.org/en/latest/orm/session_basics.html#when-do-i-construct-a-session-when-do-i-commit-it-and-when-do-i-close-it
[3]
https://specs.openstack.org/openstack/oslo-specs/specs/kilo/make-enginefacade-a-facade.html
On Thu, Sep 22, 2016 at 4:45 PM, Michał Dulko wrote:
Hi,
I've just noticed another Cinder bug [1], similar to past bugs [2], [3].
All of them have a common exception causing them:
sqlalchemy.orm.exc.DetachedInstanceError: Parent instance
<{$SQLAlchemyObject} at {$MemoryLocation}> is not bound to a Session;
lazy load operation of attribute '{$ColumnName}' cannot proceed
We've normally fixed them by simply making the $ColumnName eager-loaded,
but as there's another similar bug report, I'm starting to think that we
have some issue with how we're managing our DB connections and
SQLAlchemy objects are losing their sessions too quickly, before we'll
manage to lazy-load required stuff.
I'm not too experienced with SQLAlchemy session management, so I would
welcome any help with investigation.
Thanks,
Michal
[1] https://bugs.launchpad.net/cinder/+bug/1626499
[2] https://bugs.launchpad.net/cinder/+bug/1517763
[3] https://bugs.launchpad.net/cinder/+bug/1501838
__
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 Development Mailing List (n
[openstack-dev] [tripleo] all OVB jobs failing on stable/newton - neutron fails to sync db
Hi, I haven't investigated yet (I'll probably look over the week-end), but I found out that all OVB jobs running in our stable/newton CI are failing for the same reason: neutron-db-manage fails to run: https://bugs.launchpad.net/tripleo/+bug/1629542 I pasted the Python trace, we might hit a packaging bug or something backported upstream in stable:newton. Any help on this one is very welcome, 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
